fix(databases): preserve runtime-only relationship attrs on resetDatabases() (RE-7)

The removal loop in initStores() was dropping runtime-only attributes — like
relationship attrs added via GraphQL `@relationship` — because table()'s
persistence loop intentionally `continue`s past them (databases.ts:1138), so
they appear in `existingAttributes` (table.attributes) but not in the
`attributes` list rebuilt from attributesDbi. updatedAttributes() then stripped
the resolver/search support, breaking nested GraphQL queries after any
resetDatabases() / hot-reload — the symptom that showed up in CI as 8 failing
`handles query by nested attribute` assertions in graphql-querying-test and the
404/501 RESTProperties failures.

Also fixes a splice-while-iterating bug in the same loop: splicing the array
being walked by `for...of` skipped the next element, so two adjacent removals
(e.g. `breed` and `age` in the regression test) only dropped one. The loop now
collects into `toRemove` and applies the splices after iteration.

Adds a unit test that injects a relationship attr and asserts it survives a
resetDatabases() call, and extends the removal test's comment to explain why
the two-adjacent-removal pattern is intentional.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Author: kriszyp

resources/databases.ts

@@ -638,6 +638,10 @@ function initStores(
 				logger.error(`Error trying to update attribute`, attribute, existingAttributes, indices, error);
 			}
 		}
+		// Collect removals first; splicing while iterating `existingAttributes` skips adjacent
+		// elements, which would silently leave stale fields behind when two or more were dropped
+		// in the same reload.
+		const toRemove = [];
 		for (const existingAttribute of existingAttributes) {
 			const attribute = attributes.find((attribute) => attribute.name === existingAttribute.name);
 			if (!attribute) {
@@ -658,15 +662,22 @@ function initStores(
 				}
 				if (existingAttribute.indexed) {
 					// we only remove attributes if they were indexed, in order to support dropAttribute that removes dynamic indexed attributes
-					existingAttributes.splice(existingAttributes.indexOf(existingAttribute), 1);
-					attributesUpdated = true;
+					toRemove.push(existingAttribute);
 				} else if (!existingAttribute.isPrimaryKey) {
-					// Remove non-indexed attributes that are no longer present in the persisted schema.
-					existingAttributes.splice(existingAttributes.indexOf(existingAttribute), 1);
-					attributesUpdated = true;
+					// Skip runtime-only attributes (e.g. relationship attrs — table()'s persistence loop
+					// `continue`s past them at line 1138). They are present in `existingAttributes` but
+					// never in the `attributes` list rebuilt from attributesDbi; removing them would drop
+					// the resolver/search support added by updatedAttributes(). Computed attrs ARE
+					// persisted, so only `relationship` is excluded here.
+					if (existingAttribute.relationship) continue;
+					toRemove.push(existingAttribute);
 				}
 			}
 		}
+		for (const existingAttribute of toRemove) {
+			existingAttributes.splice(existingAttributes.indexOf(existingAttribute), 1);
+			attributesUpdated = true;
+		}
 		if (table && !recreateForEngineChange) {
 			if (attributesUpdated) {
 				table.schemaVersion++;

unitTests/resources/schemaMigrationFragility.test.js

@@ -450,7 +450,10 @@ describe('schema-migration fragility: non-indexed attributes missing from table.
 		// table() updates in-memory Table.attributes directly (databases.ts:997), so after the
 		// call above the in-memory state is already [id, name].  Re-create the stale main-thread
 		// view — still holding the old [id, name, breed, age] — so that the removal loop in
-		// initStores() actually needs to drop breed and age.
+		// initStores() actually needs to drop breed and age.  Two adjacent removals (breed AND
+		// age) also guard against a regression of the splice-while-iterating bug: splicing the
+		// array being iterated by `for...of` skipped the next element, so the loop must collect
+		// removals first and apply them after the iteration.
 		const tblForRemoval = getDatabases()[DB]?.[TABLE];
 		tblForRemoval.attributes.splice(
 			0,
@@ -467,6 +470,33 @@ describe('schema-migration fragility: non-indexed attributes missing from table.
 		assert.ok(!attrNames.includes('breed'), `"breed" should be removed, got: ${attrNames}`);
 		assert.ok(!attrNames.includes('age'), `"age" should be removed, got: ${attrNames}`);
 	});
+
+	it('preserves runtime-only relationship attributes across resetDatabases()', () => {
+		// Relationship attrs are runtime-only — table()'s persistence loop skips them
+		// (databases.ts:1138, `if (attribute.relationship) continue`), so they are present in
+		// table.attributes but never written to attributesDbi.  After resetDatabases(),
+		// initStores() rebuilds `attributes` from attributesDbi only — so the relationship attr
+		// won't appear there.  The removal loop must not drop it; otherwise updatedAttributes()
+		// would strip the resolver/search support and downstream GraphQL nested queries return
+		// undefined (the integration symptom: graphql-querying-test "handles query by nested
+		// attribute" assertions).
+		table({
+			table: TABLE,
+			database: DB,
+			attributes: [{ name: 'id', isPrimaryKey: true }, { name: 'name' }],
+		});
+		const tblWithRel = getDatabases()[DB]?.[TABLE];
+		// Inject a runtime-only relationship attribute, mirroring what graphql.ts does after
+		// parsing a `@relationship` directive — these never round-trip through attributesDbi.
+		tblWithRel.attributes.push({ name: 'related', relationship: { from: 'relatedId' } });
+		resetDatabases();
+		const tbl = getDatabases()[DB]?.[TABLE];
+		const attrNames = tbl.attributes.map((a) => a.name);
+		assert.ok(
+			attrNames.includes('related'),
+			`relationship attribute "related" should survive resetDatabases() but was dropped — got: ${attrNames}`
+		);
+	});
 });
 
 describe('schema-migration fragility: stale store reused after LMDB to RocksDB engine migration (F4)', () => {