A batch of rule changes has no record of its own, so its first change stands in for it #181

New Issue

2026-10-06T21:25:05Z

cgalo5758 commented

2026-10-06 21:25:05 +00:00

A batch of rule changes writes one core.entitlement_set_changes row per rule and none for the batch. internal/entitlements/rule_change.go ties the rows together by writing a fresh identifier into request_id, which the data model describes as a log-tracing id, so the request's own id is dropped and RuleChangeInput.RequestID is ignored. The first change stands for the batch: its sync path and counts, the movement on keys no rule names, the drain's starting point. Obligations are stored per change and pool, yet one recomputation settles them all.

Done when: a batch row owns the identifier, count, sync path, unowned effects and one obligation per pool, and request_id holds the request's id again. #113 would read from it.

A batch of rule changes writes one `core.entitlement_set_changes` row per rule and none for the batch. `internal/entitlements/rule_change.go` ties the rows together by writing a fresh identifier into `request_id`, which the data model describes as a log-tracing id, so the request's own id is dropped and `RuleChangeInput.RequestID` is ignored. The first change stands for the batch: its sync path and counts, the movement on keys no rule names, the drain's starting point. Obligations are stored per change and pool, yet one recomputation settles them all. Done when: a batch row owns the identifier, count, sync path, unowned effects and one obligation per pool, and `request_id` holds the request's id again. #113 would read from it.

cgalo5758 added the

kind

design

area/entitlements labels 2026-10-06 21:25:05 +00:00

cgalo5758 referenced this issue

2026-10-06 21:26:09 +00:00

A count of pools still waiting to be recomputed never says how long they have waited #81

cgalo5758 referenced this issue

2026-10-07 00:16:54 +00:00

A tier change keeps its cause and the operator's note in one text column, and nothing ties together the rows one act writes #179

cgalo5758 commented

2026-10-07 00:16:55 +00:00

#179, #181 and #184 share one gap: an action that writes several rows has no record of its own, so readers rebuild it from prefixes, a borrowed request id, or the shape of a workflow id. They take one convention, decided by whichever is worked first and followed by the others. #184 comes first, because the published protocol (#171) needs its answer. #131 asks the same of subscription changes.