You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Context
Tags are often used in TAMS to explore features before committing to baking them into the spec. Some tags in this class have been in use for some time now (e.g. flow_status). We should review our tags listing and elevate tags to the core spec where appropriate.
Actions
Review tags for potential elevation to the core spec
Write and ADR documenting the decision process for candidates for elevation
Review this with the TSC, and wider community as appropriate
Make the relevant spec changes, and changes to AppNote0003
Outcome
Tags have been reviewed for elevation to the core spec, and elevated as appropriate.
The flow_status is a good candidate for elevation as there are now multiple solutions using this to detect whether a flow is currently ingesting or closed. There are a few interesting extensions on this one that probably should be discussed including whether the store should actively do anything with this tag (eg close it after a period of time) or leave for the ingest tool to deal with. Also there has been request to roll the status up from the flows to an overall status at the top source level. So needs scoping and discussion and may be worth creating it's own ticket
Another consideration on flow_status is where an ingester is being swapped out without interruption of the ingest. The clean shutdown of the initial ingester might currently result in a closed_complete. One option would be to drop the status back to awaiting_content. Or we could consider adding a further state to aid in that handover.
TSC 2026-05-24
JS: Finally got to going through this: reviewed in #227 and confirmed everything is (nearly) the right status - remaining ones tidied up in that PR.
JB: Is flow status a separate PR or is that in here?
JS: It's in here
JS: Also added some wording into description pointing at the flow transform appnote on how you may want to automate managing Flow lifecycle, but it isn't in the core spec
SMG: Can we merge this now?
DJ: No dedicated endpoint to change it. Don't like having dedicated endpoint to change it, but the frequency of change might justify it?
JS: I'm ok with that.
Activity
johnbilt commentedon May 29, 2026
The flow_status is a good candidate for elevation as there are now multiple solutions using this to detect whether a flow is currently ingesting or closed. There are a few interesting extensions on this one that probably should be discussed including whether the store should actively do anything with this tag (eg close it after a period of time) or leave for the ingest tool to deal with. Also there has been request to roll the status up from the flows to an overall status at the top source level. So needs scoping and discussion and may be worth creating it's own ticket
j616 commentedon May 29, 2026
Another consideration on
flow_statusis where an ingester is being swapped out without interruption of the ingest. The clean shutdown of the initial ingester might currently result in aclosed_complete. One option would be to drop the status back toawaiting_content. Or we could consider adding a further state to aid in that handover.samdbmg commentedon Jul 24, 2026
TSC 2026-05-24
JS: Finally got to going through this: reviewed in #227 and confirmed everything is (nearly) the right status - remaining ones tidied up in that PR.
JB: Is flow status a separate PR or is that in here?
JS: It's in here
JS: Also added some wording into description pointing at the flow transform appnote on how you may want to automate managing Flow lifecycle, but it isn't in the core spec
SMG: Can we merge this now?
DJ: No dedicated endpoint to change it. Don't like having dedicated endpoint to change it, but the frequency of change might justify it?
JS: I'm ok with that.
Agreed to merge once changes reviewed