fix(flows): normalize bare-scope jq in condition expressions + prompt guard (B17)#4707
Conversation
…gainst mixing (B17) The builder emitted condition fields like `=item.labels | any(.name == "in progress") | not` — shorthand bare key (`item`, no leading dot) piped into jq. expr::run_jq compiled bare `item` as an undefined jq function → Null → condition routed ALL items to false → 0 output (proven live: 95 real issues all filtered). - vendor/tinyflows -> 68590ed (tinyflows#6): normalize_bare_scope_ref prepends `.` when a jq program starts with a bare top-level scope key (item/items/run/nodes) so `=item.labels | …` resolves as field access; leading-dot exprs + jq builtins (`any(...)`) untouched. - prompt.md: warn the builder to never mix the shorthand with jq — use `=.item.x | …` (leading dot) for any piped/functional expression; plain `=item.x` shorthand is fine alone. tinyflows 310 pass; openhuman cargo check clean; flows:: 413 pass.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 29 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7c87762a23
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| - **Never mix the shorthand with jq.** If an expression uses `|`, `[`, | ||
| functions (`any(...)`, `length`), or any jq beyond a plain dotted path, it | ||
| MUST start with `.` (the jq root): write |
There was a problem hiding this comment.
In cases where the builder needs a valid jq expression that starts with a literal rather than a root field—such as array/object construction with =[.item.a, .item.b]—this wording says any jq beyond a dotted path must start with ., so following it either forbids supported filters or can lead to invalid rewrites like =.[...]. Please scope the guard to expressions that begin with a bare scope key (item/items/run/nodes) before jq syntax.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch — fixed in f50bc2d. Scoped the guard explicitly to expressions that begin with a bare scope key (item/items/run/nodes); expressions that already start with valid jq syntax like =[.item.a, .item.b] are called out as not needing the leading dot. The underlying Rust normalizer (normalize_bare_scope_ref in tinyflows) was already scoped this way — it only fires when the program's leading char is alphabetic and the leading identifier matches a scope key — this was purely a prompt-wording precision fix for the builder LLM.
|
@coderabbitai review |
✅ Action performedReview finished.
|
…addresses @chatgpt-codex-connector on prompt.md:312) The prior wording said "any expression that uses |, [, functions... must start with a dot", which read as applying even to expressions that already begin with valid jq syntax (e.g. `=[.item.a, .item.b]` for array construction) — following it literally would prepend a stray leading dot and change the expression's meaning. Scope the guard explicitly to expressions that begin with a bare scope key (item/items/run/nodes).
1 participant
Fixes B17 — the last hop for condition-based flows. The builder emitted
field:"=item.labels | any(.name == \"in progress\") | not"(the simple-path shorthanditem.labelspiped into jq).expr::run_jqcompiled bareitemas an undefined jq function →Null→ theconditionrouted all 95 real issues to false → 0 output. (B1→B15→B16 had gotten the real data flowing; this was the final blocker.)Fix
68590ed):normalize_bare_scope_refprepends.when a jq program starts with a bare top-level scope key (item/items/run/nodes) followed by./|/[/=item.labels | any(…)resolves as jq field access. Leading-dot exprs and jq builtins (any(...)etc., followed by() are untouched; only currently-null-returning hybrids change. 5 expr tests + a condition-node jq test.prompt.md: warn the builder to never mix the shorthand with jq — use a leading dot (=.item.x | …) for any piped/functional expression.Verification
tinyflows 310 pass · openhuman
cargo checkclean ·flows::413 pass.