MigrationRegistry cannot record a migration that already ran: appliedAt is always block.timestamp

[thedavidmeister]

MigrationRegistry.applyMigration stamps block.timestamp and offers no way to say otherwise:

sApplied[msg.sender][migration] = block.timestamp;

So a writer can only record a migration as having been applied now. A deploy script that already ran — before this registry existed on the chain, or before the writer started recording at all — has no way to register itself with the time it actually ran. Its options are to record a time that is wrong, or not to appear in the record at all.

Both of those defeat what the registry is for. applied(writer, migration) is read to answer "when did this writer apply this migration", and a backfilled record that says "today" answers it wrongly for every historical migration. Leaving it out instead makes the namespace's head wrong too, because applyMigration refuses anything not applied onto the current head — so a writer that skipped its past migrations cannot record the next one either, and the whole namespace is stuck at genesis.

Ask

Let the caller supply the applied-at timestamp when registering a migration that already ran.

What this has to settle, and does not yet

• Which guarantee an author-supplied timestamp actually removes. The record is namespaced by msg.sender and there is no authority, so every entry is already only as trustworthy as the writer that wrote it — a reader asking about a namespace it trusts is reading something only that authority could have written. What a reader can rely on today, and would stop being able to, is that appliedAt is a block time and therefore monotonic and bounded by the block it landed in.
• Whether a supplied timestamp may be in the future, and whether it must be greater than the namespace's previous record. Append-only per writer is currently a property of the head, not of the times; a settable timestamp makes "the record goes forwards" a separate thing to decide.
• Whether this is the same entry point or a second one. applyMigration(expectedHead, migration) is the live signature; a appliedAt parameter changes it, and an overload leaves two ways to write one record.
• ZeroTimestamp becomes a caller-input check, not an environment one. Zero is currently refused because applied reads it as "never applied" while the head has moved — that reasoning is unchanged, but the check moves from guarding against a zero-genesis chain to guarding against a caller passing zero, which is the ordinary case rather than the exotic one.

Cost of the change

None of the kind first assumed here. This section originally claimed the
registry was deployed and pinned by consumers, so a signature change meant
IMigrationRegistryV2 and a consumer migration. That is false: no release has
ever been cut. src/generated/ holds only candidate/, and
LibMigrationRegistryReleased.releasedSuites() returns an empty array. The
sol-v* tags are soldeer package releases and pin no deployed address.

With an empty release record there is nothing to stay compatible with, so the
change lands in place on MigrationRegistry / IMigrationRegistryV1 /
LibMigrationRegistry. See the correction comment below for the full evidence
and the settled answers to the four questions above.

[thedavidmeister]

Correction: the premise of "Cost of the change" is false, and it is what shaped PR #131.

That section reads:

MigrationRegistry is deployed and its address and codehash are pinned by consumers — a signature change is a new contract at a new deterministic address, so this is IMigrationRegistryV2 and a migration of the consumers that pin V1, not an edit to what is on chain.

Every clause of that is wrong on this repo. Verified against main:

• src/generated/ contains exactly one entry, candidate/. There is no frozen src/generated/<tag>/ directory, so no release has ever been cut.
• src/lib/LibMigrationRegistryReleased.sol's releasedSuites() returns new DeploySuite[](0).
• sol-v0.1.5 is c6ec805 "Package Release: soldeer rain-deploy 0.1.6" — a soldeer package release, not a deploy-record freeze. src/generated/ does not exist at that tag at all.

With an empty release record there is nothing for a consumer to pin, no compatibility surface to preserve, and no migration to perform. The V2 apparatus solved a problem this repo does not have — 11 files and +2948 lines of it.

Ruling: no V2. The change lands in place on MigrationRegistry / IMigrationRegistryV1 / LibMigrationRegistry. PR #131 is rewritten accordingly and is now +1657/-183 across 10 files.

The rest of the issue stands, and its four open questions are settled:

1. Which guarantee a caller-supplied timestamp removes — it removes "appliedAt is a block time". Ordering is not left to the clock: each record now stores the head it was applied onto, so entries form a linked list and total order is a property of the chain.
2. May it be in the future, must it exceed the previous — no future timestamps (FutureTimestamp), and monotonic allowing equal against the record at the current head (TimestampBeforeHead). Equal accepted, earlier refused, no comparison at genesis.
3. Same entry point or a second one — a second one, named applyMigrationHistory. applyMigration stays the two-argument atomic form that stamps block.timestamp inline with the script doing the applying.
4. ZeroTimestamp — stays, now guarding a caller passing zero rather than a zero-genesis chain.