Support schema references for Avro, Protocol Buffer, and JSON schema #197

bifrost · 2022-03-16T08:43:53Z

In this pull request, the library has been extended, so the schemas can refer to other registered schemas. The implementation is recursive and it is able to handle multi-level schema references.

The referred schemas are fetched from the schema-registry and are kept in order, so the referred schemas can be processed before the referring schemas. The referred schemas are then processed by the respective schema and schema helpers.

The Avro implementation is using the typeHook and is inspired from #92

Also three new documentation pages for references have been added: schema-json.md, schema-protobuf.md and schema-avro.md

Regards
Dan Rasmussen
SumUp

In this pull request, the library has been extended, so a Protobuf Schema or a JSON Schema can refer to other registered schemas. The implementation is recursive and it is able to handle multi-level Schema nesting.

Add documentation for nested references

add nested nested references for avro

add avro doc for nested references

cleanup-ts

refactor-referredSchemas

refactoring-and-improve-examples

hilleer · 2022-03-21T09:40:51Z

Hi @Nevon

Are you able to assist here or know who could be able to help us in considering this pull request? It seem like an already requested functionality in other pull requests

Nevon · 2022-03-21T09:59:19Z

I have a review in progress, but not finished yet. Realistically, the soonest I will have enough time available is April 4-8.

I haven't yet looked at how the JSON Schema and Protobuf implementations work, but one thing that stood out to me in reading through the Avro implementation is the usage of typehooks. It's not clear to me how this feature will work when users are already using typehooks to implement logical types, especially in nested schemas. From a cursory look, it doesn't look like the implementation is taking this into account since it doesn't wrap the user-provided typehook.

enable-typeHook-for-referred-schemas

bifrost · 2022-03-22T12:54:55Z

Hi @Nevon
I change the code, so schema references always are parsed for Avro even if a usertypeHook is defined. The typeHook will be called for each avro.Type.forSchema call in the getAvroSchema method.
I have also added a test that uses a user-defined typeHook for parsing enums https://github.com/debitoor/confluent-schema-registry/blob/master/src/SchemaRegistry.avro.spec.ts#L440

bifrost · 2022-04-19T07:33:40Z

Hi @Nevon

when do you have time to have a look at the pull request? The update should handle user-provided typeHook as you requested.

Nevon · 2022-06-07T11:45:42Z

I'm currently away on vacation until June 25th, so sometime during that week.

Nevon

I totally forgot to come back to this PR once I was back from vacation. Sorry about that.

I even had an in-progress review that was pending from back then, which I'm submitting now.

I have added a calendar event to block time for myself to go through this properly this Friday, and will come back with any additional feedback then.

Sorry again for the huge wait.

Nevon · 2022-03-16T15:24:01Z

package.json

@@ -1,6 +1,6 @@
 {
  "name": "@kafkajs/confluent-schema-registry",
-  "version": "3.2.1",
+  "version": "3.3.0",


Please remove this. We'll do the version bump and release separately.

Suggested change

"version": "3.3.0",

"version": "3.2.1",

Nevon · 2022-03-16T15:34:21Z

docs/schema-avro.md

+}
+```
+
+To registry schemas with references they have to be registered in reverse order, so the referred schemas already exists. In this case B has to be registered before A. Furthermore A must define an array references to the referred schemas. A reference consist of a `name`, that should match the namespace + name, a schema `subject` and a schema `version`.


Suggested change

To registry schemas with references they have to be registered in reverse order, so the referred schemas already exists. In this case B has to be registered before A. Furthermore A must define an array references to the referred schemas. A reference consist of a `name`, that should match the namespace + name, a schema `subject` and a schema `version`.

To register schemas with references, the schemas have to be registered in reverse order. The schema that references another schema has to be registered after the schema it references. In this example B has to be registered before A. Furthermore, when registering A, a list of references have to be provided. A reference consist of:

* `name` - the fully qualified name of the referenced schema. Example: `test.B`

* `subject` - the subject the schema is registered under in the registry

* `version` - the version of the schema you want to use

Cleaned this up a little bit. One thing I'm not clear about is this bit:

A reference consist of a name that should match the namespace + name , a schema subject and a schema version.

Isn't name actually the type used within the referencing schema? If so, shouldn't we call this type to make the connection clearer? I haven't read through the code yet, but my understanding so far is that a reference is a mapping between a type and a subject-version. If that's correct, I would expect it to be { [type: string]: { subject: string; version: number } }, since right now it's undefined what happens if you provide multiple references with the same name.

Ah okay, I understand, you're trying to match the Java API, where it is called name and is (for Avro) the fully qualified name of the schema. Makes sense. Updated my suggestion to match.

Nevon · 2022-03-16T15:39:27Z

docs/schema-json.md

+	"type": "object",
+	"properties": {
+		"id": { "type": "number" },
+		"b": { "$ref": "https://sumup.com/schemas/B" }


Suggested change

"b": { "$ref": "https://sumup.com/schemas/B" }

"b": { "$ref": "https://example.com/schemas/B" }

Let's use a reserved domain from good ol' RFC 2606

There's a bunch of these, so just a global search and replace for sumup.com -> example.com.

Nevon · 2022-03-16T15:39:39Z

docs/schema-json.md

+
+```JSON
+{
+	"$id": "https://sumup.com/schemas/B",


Suggested change

"$id": "https://sumup.com/schemas/B",

"$id": "https://example.com/schemas/B",

Nevon · 2022-03-16T15:41:41Z

docs/schema-json.md

+}
+```
+
+To registry schemas with references they have to be registered in reverse order, so the referred schemas already exists. In this case B has to be registered before A. Furthermore A must define an array references to the referred schemas. A reference consist of a `name`, that should match the $ref, a schema `subject` and a schema `version`.


Suggested change

To registry schemas with references they have to be registered in reverse order, so the referred schemas already exists. In this case B has to be registered before A. Furthermore A must define an array references to the referred schemas. A reference consist of a `name`, that should match the $ref, a schema `subject` and a schema `version`.

To register schemas with references, the schemas have to be registered in reverse order. The schema that references another schema has to be registered after the schema it references. In this example B has to be registered before A. Furthermore, when registering A, a list of references have to be provided. A reference consist of:

* `name` - A URL matching the `$ref` from the schema

* `subject` - the subject the schema is registered under in the registry

* `version` - the version of the schema you want to use

Nevon · 2022-03-16T15:48:49Z

docs/schema-avro.md

+
+To registry schemas with references they have to be registered in reverse order, so the referred schemas already exists. In this case B has to be registered before A. Furthermore A must define an array references to the referred schemas. A reference consist of a `name`, that should match the namespace + name, a schema `subject` and a schema `version`.
+
+Notice the library will handle an arbitrary number of nested levels.


Suggested change

Notice the library will handle an arbitrary number of nested levels.

The library will handle an arbitrary number of nested levels.

Nevon · 2022-03-16T15:51:15Z

src/@types.ts

@@ -60,16 +67,28 @@ export interface ConfluentSubject {
 export interface AvroConfluentSchema {
  type: SchemaType.AVRO
  schema: string | RawAvroSchema
+  references?: ReferenceType[]


Let's call this a SchemaReference instead. Everything in this file is a Type, after all, so there's no point in including the word Type in there.

Nevon · 2022-03-16T16:24:57Z

src/AvroHelper.ts

@@ -21,7 +24,24 @@ export default class AvroHelper implements SchemaHelper {
      ? schema
      : this.getRawAvroSchema(schema)
    // @ts-ignore TODO: Fix typings for Schema...
-    const avroSchema: AvroSchema = avro.Type.forSchema(rawSchema, opts)
+
+    // eslint-disable-next-line @typescript-eslint/no-this-alias


You don't need to do this if you use an arrow function.

const avroSchema = avro.Type.forSchema(rawSchema, { ...opts, typeHook: opts?.typeHook ?? ((_schema: avro.Schema, opts: AvroOptions) => { // Since AvroOptions is a superset of ForSchemaOptions and `referredSchemas` is optional, we don't need to cast opts?.referredSchemas?.forEach(subSchema => { const rawSubSchema = this.getRawAvroSchema(subSchema) avroOpts.typeHook = undefined avro.Type.forSchema(rawSubSchema, avroOpts) }) // avsc allows returning undefined, and will use the default type in that case, but the typings don't allow it, // hence this little hack return (undefined as unknown) as avro.Type; }), })

Nevon · 2022-03-16T16:28:28Z

src/AvroHelper.ts

+          const avroOpts = opts as AvroOptions
+          avroOpts?.referredSchemas?.forEach(subSchema => {
+            const rawSubSchema = me.getRawAvroSchema(subSchema)
+            avroOpts.typeHook = undefined


Why remove the typehook here? Doesn't that mean that any type extensions will fail in nested schemas?

Nevon · 2022-03-16T16:38:42Z

src/AvroHelper.ts

+      ...opts,
+      // @ts-ignore
+      typeHook:
+        opts?.typeHook ||


So this would mean that you can either use a typehook or you can use schema references? A better solution might be to wrap the user's typeHook and execute it after we do our reference resolution. Something like:

const avroSchema = avro.Type.forSchema(rawSchema, { ...opts, typeHook: (_schema, opts: AvroOptions) => { const { referredSchemas, ...rest } = opts referredSchemas?.forEach(subSchema => { const rawSubSchema = this.getRawAvroSchema(subSchema) rest.typeHook = undefined avro.Type.forSchema(rawSubSchema, opts) }) if (opts.typeHook) { return opts.typeHook(_schema, rest as ForSchemaOptions) } return (undefined as unknown) as avro.Type }, })```

Nevon

My biggest question mark is around compatibility with the options for Avro schemas. I'm not sure that the options are actually being respected for both the old API and new API, and the added tests are only exercising the legacy API, as far as I can tell.

Nevon · 2022-09-30T07:50:41Z

docs/schema-avro.md

+}
+```
+
+To registry schemas with references they have to be registered in reverse order, so the referred schemas already exists. In this case B has to be registered before A. Furthermore A must define an array references to the referred schemas. A reference consist of a `name`, that should match the namespace + name, a schema `subject` and a schema `version`.


This is just food for thought and not something I think should hold up the adoption of this PR, but given the complexity of determining the registration order of schemas, perhaps we should offer a way to register multiple schemas in a single function call, i.e. await registry.register(schema: Schema[]) so that we can determine which order the schemas need to be registered in instead of having the user needing to figure that out.

Nevon · 2022-09-30T07:55:06Z

src/@types.ts

 export type JsonOptions = ConstructorParameters<typeof Ajv>[0] & {
  ajvInstance?: {
    compile: (schema: any) => ValidateFunction
  }
+  referredSchemas?: JsonConfluentSchema[]


I don't love the named referredSchemas since both we and the registry use the term reference for this feature, and the types are called SchemaReference, ReferenceType etc. It seems more natural to me to replace all instances of referred with referenced, i.e. referencedSchemas, addReferencedSchemas etc. That way it's obvious that this is related to the "schema refererences" feature.

Nevon · 2022-09-30T08:11:36Z

src/SchemaRegistry.ts

+  ) {
+    const helper = helperTypeFromSchemaType(schema.type)
+    const referredSchemas = await this.getReferredSchemas(schema, helper)
+    return helper.updateOptionsFromSchemaReferences(options as ProtocolOptions, referredSchemas)


I don't really understand the casting of options to ProtocolOptions here. I don't think we know that options isn't LegacyOptions at this point, since the type hasn't been narrowed down to ProtocolOptions.

I think you have to do something similar to

confluent-schema-registry/src/schemaTypeResolver.ts

Lines 69 to 92 in 05a3613

try {

let schema: Schema

switch (confluentSchema.type) {

case SchemaType.AVRO: {

const opts: AvroOptions | undefined =

(options as LegacyOptions)?.forSchemaOptions ||

(options as ProtocolOptions)?.[SchemaType.AVRO]

schema = (helperTypeFromSchemaType(confluentSchema.type) as AvroHelper).getAvroSchema(

confluentSchema,

opts,

)

break

}

case SchemaType.JSON: {

const opts: JsonOptions | undefined = (options as ProtocolOptions)?.[SchemaType.JSON]

schema = new JsonSchema(confluentSchema, opts)

break

}

case SchemaType.PROTOBUF: {

const opts: ProtoOptions | undefined = (options as ProtocolOptions)?.[SchemaType.PROTOBUF]

schema = new ProtoSchema(confluentSchema, opts)

break

}

to make sure that if you initialized the client with LegacyOptions those options are used when the schema is an Avro schema. Right now I think the updateOptions method is assuming that the options are always ProtocolOptions, which would break backwards compatibility.

The tests in SchemaRegistry.avro.spec.ts look like they are using the LegacyOptions, though, so I'm confused how this is working. I'm kinda suspecting that we end up making a frankenstein options object here by cominbing LegacyOptions with ProtocolOptions, into something like:

{ subject: 'subject', [SchemaType.JSON]: { references: [ ... ] } }

I think this is a good catch, I cannot find a test that uses LegacyOptions

😔 You're right. I could have sworn there were, but apparently not. You can see the difference here. It's a fairly minor difference, in that the options have just moved in one level to accommodate other schema types.

src/SchemaRegistry.ts

fix-review-comments-2

hilleer · 2022-10-03T13:35:44Z

src/SchemaRegistry.ts

-      const schemas = await this.getReferredSchemasFromReference(reference, helper, referencesSet)
-      referredSchemas = referredSchemas.concat(schemas)
+      const schemas = await this.getreferencedSchemasFromReference(reference, helper, referencesSet)
+      referencedSchemas = referencedSchemas.concat(schemas)


Avoid mutation.

Suggested change

referencedSchemas = referencedSchemas.concat(schemas)

referencedSchemas.push(...schemas)

hilleer · 2022-10-03T13:35:59Z

src/SchemaRegistry.ts

    schema: ConfluentSchema,
    helper: SchemaHelper,
    referencesSet: Set<string>,
  ): Promise<ConfluentSchema[]> {
    const references = schema.references || []

-    let referredSchemas: ConfluentSchema[] = []
+    let referencedSchemas: ConfluentSchema[] = []


Suggested change

let referencedSchemas: ConfluentSchema[] = []

const referencedSchemas: ConfluentSchema[] = []

This is not possible because referencedSchemas is updated

See my related comment below - instead of re-declaring referencedSchemas and mutating it, you can simply use .push to push to the array instead.

referencedSchemas.push(...schemas);

bifrost · 2022-10-03T15:24:09Z

Hi @Nevon
Thanks for your review.
I have fixed your review comments and added a test for LegacyOptions, please have a look.

hilleer · 2022-10-03T16:35:30Z

src/SchemaRegistry.ts

@@ -168,19 +246,15 @@ export default class SchemaRegistry {
    }

    const response = await this.getSchemaOriginRequest(registryId)
-    const foundSchema: { schema: string; schemaType: string } = response.data()
-    const rawSchema = foundSchema.schema
+    const foundSchema = response.data() as SchemaResponse


Do you actually want to cast the type? Otherwise it is better to define the type like this:

Suggested change

const foundSchema = response.data() as SchemaResponse

const foundSchema: SchemaResponse = response.data();

Is there an actual difference? Assuming that response.data returns any or maybe unknown, do you get any additional type safety from defining the type of foundSchema vs casting the return type of response.data? I've always thought of those two scenarios as equivalent, but maybe there are scenarios in which they aren't.

I guess for this specific case there is no actual difference, as response.data behaves like you describe. However, if you had a different example like this:

type FooObject = { value: string; key: 'string'; }; // complains because key is not included const foo: FooObject = { value: 'foo' }; // does not complain, because we specifically cast the type and allow missing properties const fooSecond = { value: 'foo' } as FooObject

It would behave equally if the function actually returned a specific/known type - casting the type we might not notice missing properties, while the defined type : SchemaResponse would be complaining. Casting would also complain, if the types do not match at all.

While response.data returns unknown I guess you are right that there's no additional type safety between the two options.

Yeah, totally, in other cases there's of course a difference. I'm just thinking about the case where we're assigning something that's any or unknown already. One thing that does come to mind in favor of not casting is if in the future the return type of response.data changes from any to Response<T> or whatever. If we were casting it to SchemaResponse then the compiler might not let us know that the type is now incompatible with whatever foundSchema is used for, whereas if we just declare foundSchema: SchemaResponse we would definitely get a compiler error if Response<T> is not compatible with SchemaResponse, which is good.

minor-refactoring

Nevon · 2022-10-04T07:00:54Z

src/JsonSchema.ts

+    if (referencedSchemas) {
+      referencedSchemas.forEach(rawSchema => {
+        const $schema = JSON.parse(rawSchema.schema)
+        // @ts-ignore


What's the compiler not liking about this? I would guess JSON.parse returns any, so I wouldn't expect the compiler to complain about you accessing $id on it. Seeing a ts-ignore makes my spider sense tingle, since there's few if any cases where it's necessary and might hide mistakes.

Nevon · 2022-10-04T07:33:08Z

src/SchemaRegistry.avro.spec.ts

+      })
+    })
+
+    describe('with enum typeHook defined', () => {


Nevon

Now I feel more comfortable with the change, now that it's tested with both the legacy and new options API. Just curious about that ts-ignore.

bifrost · 2022-10-04T08:40:35Z

The ts-ignore is needed because the ajv.d.ts does not define addSchema. Ajv extends Core and Core implements addSchema, that is why it works. Plese let me know if I can do a better or how to get types from Core?

Nevon · 2022-10-04T09:12:11Z

It's not because of Ajv, but because ajv is either an instance of AjvCore or something that implements a similar interface, and that "similar interface" is lacking addSchema. See #163 for context on why this was done.

Changing the JsonOptions type to the following should solve it:

export type JsonOptions = ConstructorParameters<typeof Ajv>[0] & {
  ajvInstance?: {
    addSchema: Ajv['addSchema']
    compile: (schema: any) => ValidateFunction
  }
  referencedSchemas?: JsonConfluentSchema[]
}

extend-ajvInstance

Nevon · 2022-10-04T10:01:58Z

Thank you for the contribution and sorry it took so long to upstream. This is now released in v3.3.0.

bifrost · 2022-10-04T10:06:35Z

Thanks a lot, Nevon - it has been a pleasure.

bifrost added 27 commits March 10, 2022 18:15

multi-references-for-protobuf

ff6a6d7

cleanup

6ee47b0

refactoring

cbf3986

refactor

15f5999

add comment

19a1028

bump package.json

064cfb6

rename updateOptionsWithSchemaReferences

3943fca

make requests parallel

b4aefa4

rename

662b0ee

rename

4ec1311

rename

54c6218

remove /* eslint-disable no-console */

00c1aaa

add nested references for json

97ceaeb

Add multi schema references for protobuf and json schema

43c09a5

In this pull request, the library has been extended, so a Protobuf Schema or a JSON Schema can refer to other registered schemas. The implementation is recursive and it is able to handle multi-level Schema nesting.

add documentation for nested references

d2bab57

Merge pull request #2 from debitoor/add-json-protobuf-documentation

21d9198

Add documentation for nested references

add-nested-references-for-avro

bc01ead

Merge pull request #3 from debitoor/add-nested-references-for-avro

25715b4

add nested nested references for avro

improve-doc

50cb210

Merge pull request #4 from debitoor/improve-doc

be3c063

add avro doc for nested references

cleanup-ts

254577e

Merge pull request #5 from debitoor/cleanup-ts

eaef078

cleanup-ts

refactor-referredSchemas

183be7f

Merge pull request #6 from debitoor/refactor-referredSchemas

54fccd1

refactor-referredSchemas

efactoring-and-improve-examples

90b41e0

Merge pull request #7 from debitoor/refactoring-and-improve-examples

fabb6f8

refactoring-and-improve-examples

Merge branch 'master' into master

1b4f9a0

msafwat-sumup approved these changes Mar 18, 2022

View reviewed changes

Merge pull request #8 from debitoor/enable-typeHook-for-referred-schemas

1a3dad2

enable-typeHook-for-referred-schemas

Merge remote-tracking branch 'upstream/master'

8a34858

eupsumup approved these changes Jun 7, 2022

View reviewed changes

soulmonk approved these changes Jun 7, 2022

View reviewed changes

Nevon reviewed Sep 28, 2022

View reviewed changes

zion03 mentioned this pull request Sep 28, 2022

This library is still maintained? #215

Closed

Nevon requested changes Sep 30, 2022

View reviewed changes

bifrost and others added 4 commits September 30, 2022 15:08

fix-review-comments-2

3c5fefe

review comments

f3c3bdf

review comments

d94bcc4

Merge pull request #9 from debitoor/fix-review-comments-2

3d2e0bb

fix-review-comments-2

hilleer reviewed Oct 3, 2022

View reviewed changes

bifrost and others added 2 commits October 4, 2022 08:27

minor-refactoring

d0c9ab9

Merge pull request #10 from debitoor/minor-refactoring

c9406c0

minor-refactoring

Nevon reviewed Oct 4, 2022

View reviewed changes

src/SchemaRegistry.avro.spec.ts

})

})

describe('with enum typeHook defined', () => {

Copy link

Member

Nevon Oct 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice!

Nevon approved these changes Oct 4, 2022

View reviewed changes

bifrost and others added 2 commits October 4, 2022 11:29

extend-ajvInstance

e193664

Merge pull request #11 from debitoor/extend-ajvInstance

0b2d05c

extend-ajvInstance

Nevon merged commit 3f4dea4 into kafkajs:master Oct 4, 2022

-To registry schemas with references they have to be registered in reverse order, so the referred schemas already exists. In this case B has to be registered before A. Furthermore A must define an array references to the referred schemas. A reference consist of a `name`, that should match the namespace + name, a schema `subject` and a schema `version`.
+To register schemas with references, the schemas have to be registered in reverse order. The schema that references another schema has to be registered after the schema it references. In this example B has to be registered before A. Furthermore, when registering A, a list of references have to be provided. A reference consist of:
+ * `name` - the fully qualified name of the referenced schema. Example: `test.B`
+ * `subject` - the subject the schema is registered under in the registry
+ * `version` - the version of the schema you want to use

	"b": { "$ref": "https://sumup.com/schemas/B" }
	"b": { "$ref": "https://example.com/schemas/B" }

	"$id": "https://sumup.com/schemas/B",
	"$id": "https://example.com/schemas/B",


		To registry schemas with references they have to be registered in reverse order, so the referred schemas already exists. In this case B has to be registered before A. Furthermore A must define an array references to the referred schemas. A reference consist of a `name`, that should match the namespace + name, a schema `subject` and a schema `version`.

		Notice the library will handle an arbitrary number of nested levels.

	Notice the library will handle an arbitrary number of nested levels.
	The library will handle an arbitrary number of nested levels.

	try {
	let schema: Schema

	switch (confluentSchema.type) {
	case SchemaType.AVRO: {
	const opts: AvroOptions \| undefined =
	(options as LegacyOptions)?.forSchemaOptions \|\|
	(options as ProtocolOptions)?.[SchemaType.AVRO]
	schema = (helperTypeFromSchemaType(confluentSchema.type) as AvroHelper).getAvroSchema(
	confluentSchema,
	opts,
	)
	break
	}
	case SchemaType.JSON: {
	const opts: JsonOptions \| undefined = (options as ProtocolOptions)?.[SchemaType.JSON]
	schema = new JsonSchema(confluentSchema, opts)
	break
	}
	case SchemaType.PROTOBUF: {
	const opts: ProtoOptions \| undefined = (options as ProtocolOptions)?.[SchemaType.PROTOBUF]
	schema = new ProtoSchema(confluentSchema, opts)
	break
	}

	referencedSchemas = referencedSchemas.concat(schemas)
	referencedSchemas.push(...schemas)

	let referencedSchemas: ConfluentSchema[] = []
	const referencedSchemas: ConfluentSchema[] = []

	const foundSchema = response.data() as SchemaResponse
	const foundSchema: SchemaResponse = response.data();

Support schema references for Avro, Protocol Buffer, and JSON schema #197

Support schema references for Avro, Protocol Buffer, and JSON schema #197

Conversation

bifrost commented Mar 16, 2022

hilleer commented Mar 21, 2022

Nevon commented Mar 21, 2022

bifrost commented Mar 22, 2022

bifrost commented Apr 19, 2022

Nevon commented Jun 7, 2022

Nevon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nevon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bifrost Sep 30, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hilleer Oct 3, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hilleer Oct 3, 2022 • edited Loading

Choose a reason for hiding this comment

bifrost commented Oct 3, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hilleer Oct 4, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nevon left a comment

Choose a reason for hiding this comment

bifrost commented Oct 4, 2022 • edited Loading

Nevon commented Oct 4, 2022

Nevon commented Oct 4, 2022

bifrost commented Oct 4, 2022

bifrost Sep 30, 2022 •

edited

Loading

hilleer Oct 3, 2022 •

edited

Loading

hilleer Oct 3, 2022 •

edited

Loading

hilleer Oct 4, 2022 •

edited

Loading

bifrost commented Oct 4, 2022 •

edited

Loading