fix: correct two example bugs caught by skills#70's review#589
Conversation
- v5-migration.md: the polling-loop example was missing await on delay(100), turning the intended ~10Hz poll into a tight loop (delay() returns a promise from node:timers/promises). - querying.md: the resellers relationship example pointed `from` at the singular `resellerId`, which the schema never declares — the indexed field is plural `resellerIds`. Both found by a cross-model review on HarperFast/skills#70 (which regenerates its rules from this repo). A third finding from that review — recommending `allowReadRecord` over `allowRead` for record-scoped authorization — was not applied: `allowReadRecord` doesn't exist in Harper; a synchronous `allowRead` override already is the correct record-scoped hook, so that example was correct as written.
There was a problem hiding this comment.
Code Review
This pull request corrects a relationship field reference in the REST querying documentation and adds missing await keywords to delay calls in the v5 migration guide examples. The review feedback correctly identifies a missing import for transaction in one of the migration guide code examples, which should be added to make the example fully functional.
| // we could also explicitly start a new transaction here for each get: | ||
| while ((await transaction(() => Table.get(target))).status !== 'ready') { | ||
| delay(100); | ||
| await delay(100); |
There was a problem hiding this comment.
In this code example, transaction is used on line 95 but is not imported from 'harper' on line 87 (which only imports getContext). To ensure the example is fully functional and copy-pasteable, please update the import statement on line 87 to include transaction:
import { getContext, transaction } from 'harper';
🚀 Preview DeploymentYour preview deployment is ready! 🔗 Preview URL: https://preview.harper-documentation.harperfabric.com/pr-589 This preview will update automatically when you push new commits. |
heskew
left a comment
There was a problem hiding this comment.
The two fixes are right (resellerIds resolves the FK mismatch; await delay(100) fixes both polling loops). One gap remains in this same example — left inline.
🤖 Draft prepared with Claude (cross-model review pipeline); reviewed and posted by @heskew.
| @@ -93,7 +93,7 @@ class MyResource { | |||
| // now we can call Table.get and it will read the latest data. | |||
| // we could also explicitly start a new transaction here for each get: | |||
| while ((await transaction(() => Table.get(target))).status !== 'ready') { | |||
There was a problem hiding this comment.
This example calls transaction(...) but it isn't imported — the import on line 87 only brings in getContext, so the snippet isn't copy-pasteable as written (same gap gemini flagged). Suggest:
import { getContext, transaction } from 'harper';
Summary
release-notes/v5-lincoln/v5-migration.md: the polling-loop example was missingawaitondelay(100)— sincedelayis imported fromnode:timers/promises, the un-awaited call turned the intended ~10Hz poll into a tight loop that hammersTable.getas fast as the read path allows.reference/rest/querying.md: theresellersrelationship example pointedfromat the singularresellerId, which the schema never declares — the indexed field is pluralresellerIds. A relationship built from this example can't resolve its foreign key.Both found by a cross-model (Codex) review on HarperFast/skills#70, which regenerates its rules from this repo — this PR fixes the source so a future regen picks up the correction.
A third finding from that review — recommending
allowReadRecordoverallowReadfor record-scoped authorization in the vector-indexing guide — was not applied:allowReadRecorddoesn't exist in Harper's actual codebase, and a synchronousallowReadoverride already is the correct record-scoped hook (confirmed againstresources/Resource.ts). That doc example was correct as written.Test plan
c5be2f9) to confirm both fixes land in the right source location.delayis a realnode:timers/promisesimport (returns a Promise) in both affected code blocks.resellerIds(plural), confirmingresellerIdin the relationship directive was a typo, not an intentional alias.