Skip to content

Confirm on a live realm that a Package's Runtime Script fires for a real event #318

Open
Open
Confirm on a live realm that a Package's Runtime Script fires for a real event#318
Labels
P3someday / nice-to-haveenhancementNew feature or requestready-for-humanNeeds a maintainer: a decision, a maintainer's Realm, or coordination

Description

@Mathih13
Mathih13
opened on Aug 24, 2026

Expected. A Package's Runtime Scripts should persist with a stable script_id and name, reconcile identically across every Shard, run in priority order with one failure never blocking the rest, and disappear everywhere when their Package is disabled or renamed, with no raw upload path.

Actual (at 87109e3c). Built and tested. Script (module/src/script_binding.rs#L65) carries the script_id primary key and a unique name; dispatch_order (module/src/script_binding.rs#L170) sorts priority ascending then script_id. clear_package_range and write_script (module/src/package_import/script.rs#L67) are the only writers to game_script, clearing the Package Script Range and rewriting it in one transaction, so a disabled, removed or renamed script cannot leave an orphan row. The live-DB suite module/tests/package_runtime_scripts.rs passes against a real SpacetimeDB standalone. lyracore packages replay now carries the script family to every named Shard alongside spell (lyracore-cli PR #54, merged), closing the one CLI gap earlier reviews of this issue flagged. What is still unconfirmed is a script actually firing from a real gameplay trigger on a live realm.

How to check. Install a Package that ships a Runtime Script bound to a real event, for example playerbots' personality scripts bound to its own playerbots.flee_at and playerbots.heal_at Package Events (packages/playerbots/data/.generated/personality.json). Publish, trigger the bound event through real gameplay, and confirm the script's answer takes effect. Disable the Package and confirm its scripts disappear from game_script on every Shard.

Done when. Both results are recorded here, with the realm and the commit.

Activity

  1. Mathih13
    added
    enhancementNew feature or request
    P3someday / nice-to-have
    ready-for-agentComplete enough to build from the issue alone, by a person or their agent
    on Aug 24, 2026
  2. Mathih13
    added a parent issue on Aug 24, 2026
  3. Mathih13
    marked this as blocked on Aug 24, 2026

  4. Mathih13 commented on Aug 24, 2026

    @Mathih13
    Mathih13
    on Aug 24, 2026
    ContributorAuthor

    This was generated by AI during triage.

    Handoff from the #317 implementation (PR #324): the host ships with no caller in a default build (one narrow dead_code allow marks it). The compiler cache has no eviction — lifecycle belongs here. Re-entry through a committed effect is refused, not queued; event bindings are where that policy should actually be decided.

  5. Mathih13 commented on Aug 31, 2026

    @Mathih13
    Mathih13
    on Aug 31, 2026
    ContributorAuthor

    This was generated by AI during triage.

    Batch relevance check, 2026-08-31: implemented and merged; open for live verification.

    • PR feat(module): reconcile Package Runtime Scripts on every Shard #358 (merged 2026-08-28) delivers every code-level acceptance criterion: game_script schema with script_id PK and unique name (module/src/script_binding.rs), reconciliation as the only writer (module/src/package_import/script.rs, clear Package Script Range then rewrite in one transaction), no raw upload reducer, priority-then-script_id dispatch order, per-script failure containment, idempotent re-publication. 64 new tests, including the live-DB suite module/tests/package_runtime_scripts.rs.
    • Remaining for a human on a live realm: install a Package with an on_login script and see it fire, then disable the Package and see the row and effect disappear. PR feat(module): reconcile Package Runtime Scripts on every Shard #358 named this as unrun (no SpacetimeDB credentials in its sandbox).
    • One wiring gap, deliberately out of the module's hands: lyracore packages replay still drives the spell family only, so realm-wide script publication currently has no CLI path (importer/src/package_delta.rs::reapply skips Script Artifacts by design). This folds into the replay-generalization follow-up issue this session files, together with the claim families items/quests/loot that shipped with the same gap.

  6. Mathih13 commented on Sep 3, 2026

    @Mathih13
    Mathih13
    on Sep 3, 2026
    ContributorAuthor

    Verification of the code half, 2026-09-02, against main 6f5f0f5.

    Live-DB suite module/tests/package_runtime_scripts.rs (cargo test -p lyracore-module --test package_runtime_scripts -- --ignored --test-threads=1, own spacetime 2.7.1 standalone): 4 passed, 0 failed. One run hit a connection closed before message completed during the harness's own spacetime publish; a re-run passed, so that is the machine, not the module.

    test a_conflicting_plan_leaves_the_shard_exactly_as_it_was ... ok
test a_package_binds_its_own_event_and_never_another_packages ... ok
test a_package_script_fires_on_a_real_event_and_a_failing_one_does_not_block_the_next ... ok
test a_packages_runtime_scripts_reconcile_onto_a_shard ... ok

    Unit suites: script_binding 7 passed, package_import::script 12 passed, runtime_script 32 passed.

    • One Package script has the same script_id, name, hash, and binding on every target Shard: Script row in module/src/script_binding.rs (script_id primary key, unique name), content hash derived at write time.
    • Re-publication is idempotent: clear the Package Script Range then rewrite, in one reducer transaction (package_import/script.rs); the live test re-applies the same plan and asserts identical rows.
    • Disabling or removing a Package removes its scripts from every target: an apply is the whole enabled plan, so a Package outside the plan leaves the table.
    • Renaming or deleting a source script cannot leave an orphan row: same clear-then-rewrite.
    • Event order is priority ascending, then script_id ascending: dispatch_order sorts by (priority, script_id).
    • No Package-independent upload path: only clear_package_range and write_script write game_script; the debug reducer runs source once and never writes.
    • Partial Shard completion reports an exact resume plan: lyracore packages replay does this for the spell family today; the script family joins it in packages replay: carry the script family to every Shard #393.

    Left open for the live realm check named in the triage comment. On the production realm the two playerbots scripts are present in game_script on every Shard after today's publish (#365), so the "see it fire" half is what remains.

    Verified by Claude (model claude-fable-5-1) via Claude Code.

  7. Mathih13
    added
    needs-live-eyeball
    and removed
    ready-for-agentComplete enough to build from the issue alone, by a person or their agent
    on Oct 8, 2026
  8. Mathih13
    changed the title [-]Runtime Scripts: reconcile Package scripts on every Shard[/-] [+]Confirm on a live realm that a Package's Runtime Script fires for a real event[/+] on Oct 8, 2026
  9. Mathih13
    added
    ready-for-humanNeeds a maintainer: a decision, a maintainer's Realm, or coordination
    and removed
    needs-live-eyeball
    on Oct 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3someday / nice-to-haveenhancementNew feature or requestready-for-humanNeeds a maintainer: a decision, a maintainer's Realm, or coordination

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions