The indexer never moves a module backwards: a late merged message writes nothing; indexer_heard and indexer_module_history read what it heard and kept (issue 1126)

Conversation 1 Commits 3 Files Changed 19

+653 -54

3 Commits

Author	SHA1	Message	Date
jschoubben	3629bcf057	Read only gitea's 404 status as not-found, so a 502 naming a sha with 404 in it is redelivered, not written backwards (issue 1126, review) mesh/delivery merged: source.main moved to novox/mesh-delivery@e753009fbc71 Details mesh/check being carried to 3629bcf057c3 on e753009fbc71 \| from f39bc10e3be7	2026-10-28 15:01:51 +01:00
jschoubben	743a3618ea	Keep back only a merge older than the one taken in, asked once per message before any write (issue 1126, review) Asking whether the merge contains the held commit refused forward merges forever on a diverged or rewritten main or a squash-merged registered head, failed every later merge when the forge no longer had the held commit, and cost one forge call per held commit. The question is now the reverse: a merge is kept back only when it is in the taken merge and differs from it. A merged message asks it once, before it writes anything, and a late message writes no module, deletion, placement or taken key. A take-in asks it once for its module. A 404 is not known to be older and is written, and said; any other failure to say leaves the message for redelivery.	2026-10-28 14:56:40 +01:00
jschoubben	77d738d973	Never let a merge move a module backwards, and make the forge messages and a module's history readable (issue 1126) The indexer wrote mesh-catalog's merge 9cdac09a back over the later 69056948, rolling kernel and mesh-build-image back on the nodes: a merged message's commit was written whatever the held one was. Before writing or deleting a module's value, the indexer now asks the forge whether the merge contains the held commit, keeps the held value when it does not and says so, and leaves the message for redelivery when the forge cannot say. Each applied merged message is said in one line with the modules written. No tool showed what the indexer heard of FORGE nor a modules key's history with times, so the cause could not be proven: the indexer now records each FORGE message it handles (sequence, deliveries, times, commit, outcome) in its state heard, read by indexer_heard, and indexer_module_history reads modules.<module>'s kept values with their times. Quick fix (Src order in writeOverlay) rejected: Src is 0 once the source moved on, as here. Thorough fix chosen: the order is the forge's, on every path that writes a module (merged message, take-in).	2026-10-28 14:48:13 +01:00

Author

SHA1

Message

Date

jschoubben

3629bcf057

Read only gitea's 404 status as not-found, so a 502 naming a sha with 404 in it is redelivered, not written backwards (issue 1126, review)

mesh/delivery merged: source.main moved to novox/mesh-delivery@e753009fbc71

Details

mesh/check being carried to 3629bcf057c3 on e753009fbc71 | from f39bc10e3be7

2026-10-28 15:01:51 +01:00

jschoubben

743a3618ea

Keep back only a merge older than the one taken in, asked once per message before any write (issue 1126, review)

Asking whether the merge contains the held commit refused forward merges
forever on a diverged or rewritten main or a squash-merged registered head,
failed every later merge when the forge no longer had the held commit, and
cost one forge call per held commit. The question is now the reverse: a merge
is kept back only when it is in the taken merge and differs from it. A merged
message asks it once, before it writes anything, and a late message writes no
module, deletion, placement or taken key. A take-in asks it once for its
module. A 404 is not known to be older and is written, and said; any other
failure to say leaves the message for redelivery.

2026-10-28 14:56:40 +01:00

jschoubben

77d738d973

Never let a merge move a module backwards, and make the forge messages and a module's history readable (issue 1126)

The indexer wrote mesh-catalog's merge 9cdac09a back over the later 69056948,
rolling kernel and mesh-build-image back on the nodes: a merged message's
commit was written whatever the held one was. Before writing or deleting a
module's value, the indexer now asks the forge whether the merge contains the
held commit, keeps the held value when it does not and says so, and leaves the
message for redelivery when the forge cannot say. Each applied merged message
is said in one line with the modules written.

No tool showed what the indexer heard of FORGE nor a modules key's history
with times, so the cause could not be proven: the indexer now records each
FORGE message it handles (sequence, deliveries, times, commit, outcome) in its
state heard, read by indexer_heard, and indexer_module_history reads
modules.<module>'s kept values with their times.

Quick fix (Src order in writeOverlay) rejected: Src is 0 once the source moved
on, as here. Thorough fix chosen: the order is the forge's, on every path that
writes a module (merged message, take-in).

2026-10-28 14:48:13 +01:00

The indexer never moves a module backwards: a late merged message writes nothing; indexer_heard and indexer_module_history read what it heard and kept (issue 1126) #96