mesh-issues: resume an interrupted carry by revision and fault one issue instead of the whole start, so no kept value is lost and the tracker always starts (review of PR 228)
mesh/merge-gate pass: builds mesh-issues → novox; no bus step; every machine composes with the change as it did without (4 of 4 compose)
mesh/repo-check pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (go), merge-check-typescript.sh (typescript)
mesh/delivery delivered
mesh/merge-gate pass: builds mesh-issues → novox; no bus step; every machine composes with the change as it did without (4 of 4 compose)
mesh/repo-check pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (go), merge-check-typescript.sh (typescript)
mesh/delivery delivered
An open's lost answer is judged by the issue's first entry; an entry that does not fold faults its issue on start; a value written beside the log is never folded over; one issue is kept in at most 252 KiB so its whole operation fits a log entry.
This commit is contained in:
@@ -167,7 +167,7 @@ It is a verb on the seat, callable by any agent, because it can do only this:
|
||||
`imported` event. What it writes comes from hq's `main` as the records module holds it, which is reviewed
|
||||
in pull requests.
|
||||
- **What it keeps is bounded** as every verb's text is: the title 200 bytes, the report 64 KiB, one issue
|
||||
256 KiB; a report that trips a credential's shape is refused. An entry of `located-in` or `fixed-by` hq
|
||||
252 KiB; a report that trips a credential's shape is refused. An entry of `located-in` or `fixed-by` hq
|
||||
wrote is prose at times, so it is taken within a reason's bound (2000 bytes), not a line's.
|
||||
- **An owner hq named that the registered list does not know is kept as written and marked**, in
|
||||
`located-in-unverified` on the issue and `unverified-owners` in the answer, never refused: the list is
|
||||
@@ -269,15 +269,22 @@ emptied bucket is rebuilt whole — and raises the issue counter to the highest
|
||||
below. Until then a `list` reads the bucket and a write carries the issue it changes first.
|
||||
|
||||
**The switch** (ADR 0300 §6) is the carry, run on every start and before any write of an issue not carried:
|
||||
for every issue the bucket holds with no `folded`, each value the bucket still keeps of it, oldest first, is
|
||||
appended as a `carried` operation holding the whole issue, and the fold written. It is idempotent: an issue the
|
||||
log already begins is not carried again (where the bucket holds something other than its fold — written by an
|
||||
instance from before the switch — that value is carried as one more operation). The values kept are read through
|
||||
the runtime's `mesh/state.history` (hq ADR 0307, the SDK's `State("issues").History`), oldest first; a deletion
|
||||
among them is passed over and counted in the start line, since the tracker never deletes an issue and every
|
||||
value after one holds the issue whole. A store that reads no history gives each issue's current value alone,
|
||||
and the start line says so. It runs on start rather than as a verb because it must precede every
|
||||
write, and a verb could be called late or never.
|
||||
for every issue the bucket holds with no `folded`, each value the bucket still keeps of it, read through the
|
||||
runtime's `mesh/state.history` (hq ADR 0307), is appended oldest first as a `carried` operation holding the
|
||||
whole issue and the bucket's revision of that value, and the fold written. It resumes rather than restarts: a
|
||||
kept value at or below the highest revision a carried operation holds, or one the tracker wrote itself (it has
|
||||
`folded`), is known to the log, so an interrupted carry, or two instances carrying one issue at once, carry each
|
||||
value once. Matched by revision, not content, because the same content may be kept twice. A value written beside
|
||||
the log after the carry, by an instance from before the switch, is carried as one more operation and is never
|
||||
written over by a fold. A deletion among the kept values is passed over and counted, since the tracker never
|
||||
deletes an issue and every value after one holds the issue whole.
|
||||
|
||||
An issue that cannot be carried — the log refusing it, or a value this module cannot read — is a fault, named
|
||||
with its reason in the start line; the others are carried and the start finishes. That issue stays in the
|
||||
bucket as it was, read and listed as before, and every write to it is refused with the same reason until it
|
||||
can be carried, so no operation reaches the log before its carry. One issue is kept in at most 252 KiB, so that
|
||||
the operation holding it whole fits one entry of the log (256 KiB). An entry of the log that cannot be folded
|
||||
faults its issue on start: nothing folded past it is written, and its bucket value is left as it is.
|
||||
|
||||
**In memory** the tracker holds every folded issue, kept current by the watch and its own writes, and a
|
||||
full-text index of title, report and notes, ranked by BM25 (title words weigh three), rebuilt on every start.
|
||||
@@ -286,7 +293,7 @@ the 500 rows one answer holds. The index is the module's own: a few thousand iss
|
||||
library of dozens of modules.
|
||||
|
||||
The other states: `counters`, one value per key (`issue`, `decision`, `research`); `grooming`, the backlog's
|
||||
pass; `reservations`, one key per reserved number. None expires. One issue is kept in at most 256 KiB; a note
|
||||
pass; `reservations`, one key per reserved number. None expires. One issue is kept in at most 252 KiB; a note
|
||||
that would pass it is refused.
|
||||
|
||||
**The events announce; the log is the audit trail.** Every change is still an event: `mesh-issues.opened`,
|
||||
|
||||
Reference in New Issue
Block a user