Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

intent: a status-filtered roll-up (where:) never recomputes on a transition - the child's -transitioned is not a roll-up trigger

Closed
  • Is something wrong?
#7,942 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #8003 by @nedelcho-delchev-tues — merged

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
53/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
backend, distributed-systems

Research direction

Start with GlueIntentGenerator.java around lines 736–752 to see which child events trigger roll-up recomputation, then trace how transitions publish the -transitioned topic in Transition.java.template. Check EdmIntentGenerator.java around lines 755–800 for the grouping keys involved. Done when a status transition that changes whether a child matches where: causes the parent roll-up to recompute; the issue suggests binding a transition handler or including the filter columns in grouping keys.

Written by the indexing model from the issue text.

Description

Problem

Take a roll-up whose where: filters the child rows by status, for example "sum only the non-voided allocations / documents" (#7542). It does not recompute when a child's status is moved by a transitions: button, a generates sourceStatus: flip or a process setter. The parent keeps counting the row the filter now excludes (or keeps ignoring the one it now includes) until some unrelated -updated of a sibling happens to fire.

Why (release commit 862f6d1a, 14.93.0)

  • A roll-up subscribes to the child's create / -updated / -deleted / -rekeyed topics only (GlueIntentGenerator.java ~L736-L752).
  • A transition writes the status through updateProperties(..., "<...>-transitioned"), which publishes only -transitioned (Transition.java.template, TransitionIntent javadoc).
  • -rekeyed does not cover it either. The grouping keys that trigger it are only the aggregates' by: and the roll-up's via FK (EdmIntentGenerator.java ~L755-L800), never the columns a where: reads.

Expected

When a roll-up has a where:, also bind a <Child>RollupOnTransition handler on the child's -transitioned topic. It is the same idempotent recompute. Alternatively, add the where: columns to the child's grouping keys so the targeted write publishes -rekeyed. Workaround used in BusinessIntents today: route the status change through a plain -updated write (the payment pattern), documented per module.

Related but distinct: #7905 (coalesced roll-ups drop a member's where:), #7869.

Found on 14.88.0 by BusinessIntents (wave 2026-10-17) and re-checked against the 14.93.0 source; still present.

🤖 Generated with Claude Code

Dominant language
Java
Stars
278
Forks
97
Avg merge
17h 19m
Merged PRs (30d)
261

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from eclipse-dirigible/dirigible

All issues in eclipse-dirigible/dirigible

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.