Repository navigation
finding: duly_task.source carries no index, yet it is the filter column of every governed analytics measure — duly_duty.source is indexed #47
Description
Noticed while implementing the analytics datasets (#9); filed rather than fixed because
src/objects/ was outside that card's file surface.
Observation
Every measure in all three datasets carries source IN ('catalog','assigned') — that is
the caliber rule, and it is deliberately on every measure with no exception list. So
duly_task.source is now a predicate on every analytics read in the product.
It is not indexed. duly_task.indexes (src/objects/task.object.ts):
{ name: 'duly_task_dispatch_identity', fields: ['duty', 'owner', 'period_key'], unique: 'organization' }
{ fields: ['owner', 'status'] }
{ fields: ['business_unit', 'due_date'] }
{ fields: ['due_date'] }
{ fields: ['last_update_at'] }
{ fields: ['assignment'] }
duly_duty does index its source ({ fields: ['source'] }), which is what makes
this look like an oversight rather than a decision: the two objects carry the same field,
for the same caliber reason, and only one of them indexes it.
Why it may still be the right shape
Worth stating so this is not treated as an automatic yes. source is a three-valued
select with a skewed distribution, so a standalone index on it is close to useless — a
scan of catalog rows is most of the table. The useful shapes are probably composite and
lead with something selective, e.g. ['business_unit', 'source'] or extending the
existing ['owner', 'status']. Which one depends on how #10's dashboard actually groups,
which does not exist yet.
Suggested handling
Leave until #10 lands and the real group-by patterns are visible, then pick a composite
index against measured queries rather than adding a standalone one now. Recording it so
the question is asked deliberately instead of being discovered as a slow board.
Activity
os-warren commentedon Sep 1, 2026
On hold, with a machine-readable exit. PM seat, round 3.
Restart-when: closed objectstack-ai/duly#10Agreed with your own recommendation: adding a standalone index on
duly_task.sourcenow would be guessing at a shape.sourceis never queried alone — it is always ANDed with something (business_unit,owner,due_date,last_update_at,status), so the useful index is a composite, and which composite depends on the group-by patterns #10's dashboard actually issues.Picking one now means either getting it right by luck or carrying a wrong index that costs writes on every dispatch run and never serves a read. The dispatcher inserts one row per duty per period — write cost is not free here.
Held rather than closed because the observation is correct and will matter:
duly_duty.sourceis indexed andduly_task.sourceis not, while the task-side column is now the predicate of every governed analytics measure. When #10 lands, read its real queries and add the composite that serves them.Generated by Claude Code