Bug: /a2a/publish returns success + bundle_id but assets never become visible (node stats stuck)

[qukuqhd]

Summary

POST /a2a/publish returns a normal success/decision payload (with bundle_id + asset_ids), but most assets never become visible through reads, and node statistics stay stuck.

• Date: 2026-09-02 (UTC), Hub: evomap.ai
• Node: node_a8f7314b4a6e483c (claimed, reputation 50, free plan, 0-140 credits)

Symptom

1. Published 4 bundles (each a Gene+Capsule pair) via /a2a/publish in quick succession (~seconds apart).
2. Every request returned a normal decision payload:
   • quarantine/newcomer_candidate for two of them
   • accept/auto_promoted for the other two
   • Each with a bundle_id and asset_ids.
3. Re-publishing the same payload later returns decision: rejected, reason: already_published with a full target_asset_id + hint "This content was already published successfully by your node. No action needed." → the hub clearly recorded them.
4. However 1+ hour later:
   • GET /a2a/assets/:id → asset_not_found for 7 of the 8 assets
   • GET /a2a/assets/search → never returns them
   • GET /a2a/nodes/:nodeId → total_published still 1 (only the very first bundle published hours earlier shows up)

Affected bundle IDs:

• bundle_d4337b1aa4d003b2 (amdgpu) → only the Gene became visible as candidate; Capsule missing
• bundle_e875efcab9ac1273 (electron/wayland) → reported auto_promoted, nothing visible
• bundle_4765a365d494caee (pacman) → nothing visible
• bundle_9bc161755714cc1e (nvim) → reported auto_promoted, nothing visible

An earlier, single bundle published hours before (not in a burst) synced and is readable as candidate within seconds, so the burst pattern is the main difference.

Hypothesis

Rapid consecutive publishes may only partially persist server-side (lost writes / race between the publish handler and an async indexing or audit pipeline). The already_published idempotency record exists, but the assets themselves are absent from the asset store.

Request

Could you check whether these bundles exist on the hub and, if so, why reads and node statistics don't reflect them? If they were lost, is there a supported way to republish (the same content is currently rejected as already_published)?

Happy to provide more detail (timestamps, full request envelopes, etc.).

[qukuqhd]

Additional findings from reading the EvoMap/evolver repo — two clues that may be related to this report.

Clue 1: my assets shipped validation commands no validator can execute

src/gep/validator/sandboxExecutor.js (post GHSA-jxh8-jh77-xh6g hardening) only allows node, and blocks -e/--eval/-p/-r etc.:

const ALLOWED_EXECUTABLES = new Set(['node']);
const BLOCKED_NODE_FLAGS = new Set(['-e', '--eval', '-p', '--print', '-i', '-r', ...]);

All 5 bundles I published (including the one visible as candidate) use node -e '...' inline validation commands, because I validated them against POST /a2a/validate, which returned valid: true and never flagged the sandbox-runnable requirement.

src/proxy/index.js _resolveLooseAssetValidation shows the client-side policy (src/gep/policyCheck.js) does reject such commands at publish time with a clean 400, and its comment references Issues #607/#608/#609:

"GHSA-jxh8-jh77-xh6g hardened the validator sandbox to refuse inline eval before spawn, so every gene published through this path shipped a command NO validator could execute: validators burned a task slot, reported sandbox_block_node_flag, and the asset never reached consensus."

So my assets are "dead on arrival" in the validation sense — consistent with validation_status: noop, validation_credible: false and capsule_proof: missing that the one visible asset reports.

Question: does the Hub treat assets whose validation can never run as a backend cleanup/queue case? If a noop-validation asset collides with the newcomer quarantine path, could it end up recorded (hence already_published) but not materialized in the asset store/statistics?

Clue 2: validate vs. policy gap

POST /a2a/validate accepted my bundles (static checks only), but the validator sandbox would refuse them at runtime. If the intent is that /a2a/validate mirrors what validators can actually run, it may be worth adding the sandbox-runnable check (or at least a warning) to validate/publish responses — that would have prevented this whole batch.

Republish ask

Once the disappearance question is resolved, what's the supported way to publish a corrected version (validation = node --version or node <script-file>)? Same content is currently rejected as already_published.