FlowId support

Hi! 

It should be possible to use flowId with other service messages (blocks, tests, progress, etc.), not just message. Have you tried to explicity define the Explicitly define the start and end of your flows?

##teamcity[flowStarted flowId='1']
##teamcity[blockOpened name='block 1' flowId='1']
##teamcity[progressMessage 'Message 1' flowId='1']
...
##teamcity[blockClosed name='block 1' flowId='1']
##teamcity[flowFinished flowId='1']

Please let me know if this helps. If it does not work for you, please share more details, such as an example script to run in a build step and the resulting build log.

Thanks

Hi Guilherme, thanks for your reply.

I tried your suggestion directly in a simple build step with the Powershell runner, with some harmless extra messages:

Write-Host "##teamcity[flowStarted flowId='1']"
Write-Host "##teamcity[blockOpened name='block 1' flowId='1']"
Write-Host "##teamcity[progressMessage 'Progress... 1' flowId='1']"
Write-Host "Something"
Write-Host "##teamcity[message text='Message 1' flowId='1']"
Write-Host "##teamcity[message text='Message 2' flowId='1']"
Write-Host "##teamcity[blockClosed name='block 1' flowId='1']"
Write-Host "##teamcity[flowFinished flowId='1']"

And this is what I got:

As you can see, the progress message isn't being written in the “block 1” block. Also, the Progress... 1' flowId='1 evaluation of the single-attribute message is telling me the parser is just evaluating anything in-between the first and last apostrophe disregarding any possible extra attribute.

Now the documentation states that:

Note that the flowStarted and flowFinished messages are in effect only when emitted between the testStarted and testFinished messages.

I'm not doing that in the context of a test but let's try:

Write-Host "##teamcity[testStarted name='Test']"
Write-Host "##teamcity[flowStarted flowId='1']"
Write-Host "##teamcity[blockOpened name='block 1' flowId='1']"
Write-Host "##teamcity[progressMessage 'Progress... 1' flowId='1']"
Write-Host "Something"
Write-Host "##teamcity[message text='Message 1' flowId='1']"
Write-Host "##teamcity[message text='Message 2' flowId='1']"
Write-Host "##teamcity[blockClosed name='block 1' flowId='1']"
Write-Host "##teamcity[flowFinished flowId='1']"
Write-Host "##teamcity[testFinished name='Test']"

And this is what I got:

Same issues suggesting a progress message can't use flowIds and they can't even be used in the context of a flow.

I'm using an older TeamCity version (2023.11.5) but the docs do not reflect any changes on this. Any clues on what to try next?

Thanks for your time!

Hey Guilherme Barbosa, I'd appreciate an answer on this. 

Also, I need clarification on why these related issues (TW-63772, TW-73612, and associated TW-8249, TW-46515) were closed as “not needed” without explanation 2 days ago. These have been unresolved for the last many years and they all describe the same issue, so you already knew FlowId is fundamentally broken when you first replied to me. If this feature never worked and isn't planned for repair, the documentation needs to be updated immediately to reflect reality, rather than implying functionality that doesn't exist. Can you confirm the status and let us know when the docs will be corrected?

Hi!

From the screenshot above, it seems your message calls did work: in both screenshots, ##teamcity[message text='Message 1' flowId='1'] and Message 2 are grouped inside "block 1". So flowId itself is being honored.
 

Regarding progressMessage, it seems my suggestion was incorrect here. It seems progressMessage only has the single-value form:
 

##teamcity[progressMessage '<text>']
 

That form has no place for attributes, so flowId='1' is not parsed as an attribute — it is taken as part of the message text. That is why the log shows the literal Progress... 1' flowId='1 and why the line lands outside the block. Wrapping it in flowStarted/flowFinished or testStarted/testFinished can't change that, because the attribute never reaches the parser in the first place. This is a property of the service-message format, not something specific to 2023.11.5.
 

As such, progressMessage isn't a log line that gets nested into a block, instead its job is to update the build's progress indicator (the text shown next to the running build), so it isn't placed inside a block even when everything parses.
 

So for what you want — grouped output attributed to a flow/block — use the attribute-form message together with blockOpened/blockClosed carrying the same flowId, which is exactly what already worked for your Message 1 / Message 2. If you specifically want a "progress-looking" line inside the block, emit it as a message rather than a progressMessage.
 

Regarding the documentation, you read them correctly, and the sentence "Any message supports the optional attribute flowId" is too broad. It holds for messages that use the attribute (name=value) syntax, but not for single-value messages like progressMessage. We will pass the feedback to our team

Regarding:

Also, I need clarification on why these related issues (TW-63772, TW-73612, and associated TW-8249, TW-46515) were closed as “not needed” without explanation 2 days ago. These have been unresolved for the last many years and they all describe the same issue, so you already knew FlowId is fundamentally broken when you first replied to me.

Regarding these issues:
-TW-63772 is marked as fixed;

-The other issues describe different problems related to these functionalities. If the mentioned issues are relevant to you, the best course of action is to interact directly with our team in the respective threads.

Regarding “you already knew FlowId is fundamentally broken when you first replied to me”, I am sorry if you perceived this negatively. We try to support users to the best of our abilities and knowledge. It might happen that we don't find an old bug report or a limitation of the feature under investigation in the process of trying to help our users. Please accept my apologies for any inconvenience caused.

We will reach out to our team to improve the documentation on this. 

Thanks,

Guilherme