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

Decide whether P6 needs batch execution (/v1/batches) now that KEDA fan-out is going away

Open
#537 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
kubernetes, typescript

Research direction

This is a design decision, not a code change, and the payload names no source file. Start with the linked #279 resolution and #490, #378 and #401, which the issue says hold the evidence for whether a batch resource is needed. Done is a recorded decision on batch versus async-session fan-out, posted as a comment, ADR or spec section. A spec in docs/specs/ follows only if the answer is yes.

Written by the indexing model from the issue text.

Description

enhancement

Problem

Batch execution (many independent prompts or leaves submitted together, run with bounded concurrency, results collected later) has no home on P6 and no issue. On the deprecated path the closest thing is async: true fan-out drained by KEDA leaf-worker pods. The #279 resolution decided there is no run noun and no second /v1/runs: user-owned async dispatch is async: true on a session, "or /v1/batches if a real batch appears". That condition is currently undecided, and removing Knative/KEDA removes the only batch-shaped capacity.

Scope

A decision first, then build only if the answer is yes.

  1. Is there a real batch need? Collect evidence from the #490 responses and from the subagents epic (#378): is fan-out of N independent leaves from one submission enough, or is a batch resource with its own lifecycle needed?
  2. If a client-side loop over async sessions is enough: document it and close this issue, noting the limits (admission, per-subject quota).
  3. If a batch resource is needed: design /v1/batches.
    • Submission and ownership, per-item state, partial failure and retry, cancel, and result retrieval.
    • Bounded concurrency through supervisor admission, and per-subject quota (#360, #391).
    • Retention (#390).
    • Declarative continuations (#401, option a) may cover the same ground. Decide whether a batch is a degenerate graph.

Acceptance

  • A recorded decision (comment, ADR or spec section) on batch versus async-session fan-out.
  • If yes: a spec in docs/specs/ and implementation issues, ordered after #386 to #390.

Related

#279 (resolution), #386, #389, #390, #391, #401, #360, #490, #378

Dominant language
TypeScript
Stars
4
Forks
9
Avg merge
9h 31m
Merged PRs (30d)
139

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 rossoctl/moca

All issues in rossoctl/moca

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.