Repository navigation
docs: fix agent guide gaps from the evaluations - #66
Conversation
The Track B and Track C agent evaluations found code and answers that
the guide did not prevent:
- The guide said this.reject(code, message). The method takes a code
and an options object: this.reject(code, { message }).
- A worker process runs only the actor classes that it knows. Run
against the published 0.17.1 package, a worker without
runtime.register left an enqueued message in ready_messages with 0
attempts and no error; with runtime.register it completed. Step 7 now
says to register each class before runtime.run(signal).
- Agent code called schedule() without an operation and named the
effect handler arguments in the wrong order. The guide lists these
mistakes with the correct form.
- The install step now says to take the current release and points to
step 5, because every authorization callback denies by default.
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Review feedback on #66. The guide said that a message for an unregistered actor class waits with no error. That was wrong. Rerun against solid-objects 0.17.1 with an instrumentation callback, the worker reported solid_objects.activation.failed six times in four seconds with errorName UnknownActorType, and returned the message to the queue each time without a counted attempt. Nothing printed without the callback, which is why the first run looked silent. The guide and the changelog now describe that failure. The step 7 note also points to the direct ref() call above instead of the step 6 class definition, which registers nothing.
|
@greptileai Please review the latest commit f518f1c. It answers both findings: the guide and CHANGELOG now describe the UnknownActorType setup failure and the activation.failed events (reproduced against 0.17.1 with an instrumentation callback), and the step 7 note points to the direct ref() call above. |
|
Docs7 for cardmagic/solid-objects-js
Commit |
Track C finished: 13 of 16 implementation attempts passed. Its report proposed three more changes, applied here: - Codex opened the agent guide in 1 of 8 attempts. The README now names the agent guide at the start of Installation. - One attempt computed expiry from the clock in a query, so a hold read as released before the reminder ran. The agent guide now says that a reminder changes state only when it runs and that a query must read the committed state. - The current-release note now also appears where Track C pointed.
|
@greptileai Please review the latest commit 9a54ff6. It adds the Track C findings: the README names the agent guide at the start of Installation, the agent guide says a reminder changes state only when it runs under runtime.run(signal), and docs/virtual-actors.md explains that the example's work branch registers TicketSale through ref(). |
| - A reminder changes state only when it runs, and it runs only while a process | ||
| calls `runtime.run(signal)`. Do not compute expiry from the clock in a query; | ||
| read the state that the reminder committed. |
There was a problem hiding this comment.
The statement that reminders run only under runtime.run(signal) excludes supported manual runners. Hosts and tests can use ReminderScheduler.runOnce(), runUntilIdle(), or run(signal) without calling runtime.run(), as docs/api.md explains. Agents following this guide may wrongly reject those valid options.
Say that a reminder changes state only when a reminder runner executes it, normally through runtime.run(signal). Update the matching wording in CHANGELOG.md too.
Prompt To Fix With AI
This is a comment left during a code review.
Path: docs/agents.md
Line: 201-203
Comment:
**Manual runners appear unsupported**
The statement that reminders run only under `runtime.run(signal)` excludes supported manual runners. Hosts and tests can use `ReminderScheduler.runOnce()`, `runUntilIdle()`, or `run(signal)` without calling `runtime.run()`, as `docs/api.md` explains. Agents following this guide may wrongly reject those valid options.
Say that a reminder changes state only when a reminder runner executes it, normally through `runtime.run(signal)`. Update the matching wording in `CHANGELOG.md` too.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
|
@greptileai Please review the latest commit 0815c5e. It prepares 0.17.2: package.json, src/version.ts, the dated CHANGELOG section, and the parity ledger's Ruby reference. No other change. |
1 participant
Why
The Track B (installed skill) and Track C (implementation) agent evaluations found answers and code that
docs/agents.mddid not prevent, and one error in the guide itself.What changes
rejectform: the guide saidthis.reject(code, message). The method isreject(code: string, options: { message: string; details? }). The guide now showsthis.reject("room_full", { message: "The room is full" }).runtime.registerreportedsolid_objects.activation.failedwithUnknownActorType(6 times in 4 seconds, visible only through an instrumentation callback) and left the message inready_messageswith 0 counted attempts. Withruntime.register(Counter), the same worker completed it. Step 7 now registers the class beforeruntime.run(signal)and explains thatref()also registers it.schedule()without an operation and named the effect handler arguments in the wrong order. A table lists these mistakes with the correct form.Validation
pnpm exec prettier --checkandnode scripts/check-documentation.mjspass.solid-objects@0.17.1from npm, by inspecting the SQLite tables after each worker run.