Shard and procedure endpoint ids change on every build

[JuanMarchetto]

#[shard] and #[procedure] mint their endpoint id with Uuid::new_v4() at macro expansion time, so every compilation produces new URLs. A browser tab left open across a deploy keeps polling the previous binary's id, and the new binary does not serve it.

Four builds of one unchanged source in an application I built produced four ids:

d646e935-433f-44a3-88ea-fe71155e2a28
68c1a3c6-...
a91567b3-...
65adb204-...

What the open tab does then, from the network log of a tab that was never reloaded:

POST /_topcoat/shards/a823c355-9fd9-438f-a470-0507653715a8 -> 200 (3ms, 969B)
POST /_topcoat/shards/a823c355-9fd9-438f-a470-0507653715a8 -> 200 (2ms, 963B)
... rebuild and restart ...
POST /_topcoat/shards/a823c355-9fd9-438f-a470-0507653715a8 -> 405 (0B)

The status is 405 rather than 404 when a catch-all page claims the path. The failure is silent in both cases: fetchAndReplace swaps the empty body in, so the fifteen rows on screen are deleted while the heading, the summary and the filter box outside the shard stay put. Nothing reaches the console and no request fails from the application's point of view. A control run confirms the rebuild causes it and not the restart: stopping and starting the same binary cost the open tab one refused connection, after which it kept polling the same URL and picked up a delivery four seconds later.

@AmeinEskinder reproduced this independently on examples/shard, three builds with only a comment changed, and found two things I had not:

• #[procedure] has the same construction at procedure.rs:123, so a stale tab's button click fails the same way.
• topcoat asset bundle compiles the crate, so the bundling step can mint fresh ids partway through a deploy sequence.

There is already a pattern for a stable opaque id in the tree: AssetId::new hashes the crate name, the source file and the asset path. Something equivalent over crate name, module path and ident would survive a rebuild while staying opaque.

One argument against determinism, which belongs in the decision rather than in a reviewer's head: a fresh id per build means a URL someone learned once stops working at the next deploy, and making ids deterministic makes that URL permanent. It is not protection either way, since the page hands the id to anyone who loads it, and shard endpoints need their own authorization regardless.

Related: #247 covers the swap that makes the failure silent, and the id churn is the other half of what an open tab experiences across a deploy.

[AmeinEskinder]

One implementation note, since "crate name, module path and ident" reads like it needs the macro to see the module path, and a proc macro can't — expansion happens before name resolution.

It doesn't need to. The macro can emit module_path!() into the generated code and hash it there, which is the same shape as AssetId::new doing its work in the declaring crate:

pub const ID: &str = {
    const H: u64 = fnv1a(stringify!(counter).as_bytes(),
        fnv1a(module_path!().as_bytes(),
            fnv1a(env!("CARGO_CRATE_NAME").as_bytes(), FNV_OFFSET)));
    const BYTES: [u8; 16] = hex(H);
    match str::from_utf8(&BYTES) { Ok(s) => s, Err(_) => panic!("hex is ascii") }
};

I checked that this compiles and that the id stays put across a rebuild of unchanged source. ShardId and ProcedureId are both &'static str newtypes with a const fn new, so the const-hex form drops straight in without touching either signature or the route path built from as_str.

The key is also collision-free for declarations at module scope, since two items can't share a name inside one module. Hashing the source file instead would not be: two modules in one file can each hold a #[shard] fn rows.

[JuanMarchetto]

You are right, and my wording was wrong: a proc macro cannot see the module path, so hashing has to happen in the expansion. Emitting module_path!() and folding it in the declaring crate is the fix, and the module-scope collision argument settles the choice against hashing the source file.

I will take the implementation, with the design credited to you. One question stays open for the maintainer before the code matters: making ids deterministic makes a shard URL permanent across deploys, and today it changes every build. You raised it first and it belongs in the decision.