Add build id to workflow info

[Sushisource]

What was changed

• Add Build ID to workflow info
• Update Core

Why?

Part of temporalio/features#253

Checklist

1. Closes

2. How was this tested:
   Added IT

3. Any docs updates needed?

[cretz]

LGTM, just have to skip the test for the time-skipping server

[cretz]

Suggested change

	async def test_workflow_current_build_id_appropriately_set(client: Client):
	async def test_workflow_current_build_id_appropriately_set(client: Client):
	if env.supports_time_skipping:
	pytest.skip("Java test server does not support worker versioning")
	if not await worker_versioning_enabled(client):
	pytest.skip("This server does not have worker versioning enabled")

Ignore this test when on time-skipping server or on older server

[Sushisource]

Worker versioning isn't actually being used here - just the fields about build id which should work in the test server, right?

[cretz]

I thought I saw a CI error when we run these tests against time skipping. But now I'm seeing some other update error in regular tests which is preventing it from getting to the time-skipping tests that show the time-skipping server failed somehow here. But yes, can just:

Suggested change

	async def test_workflow_current_build_id_appropriately_set(client: Client):
	async def test_workflow_current_build_id_appropriately_set(client: Client):
	if env.supports_time_skipping:
	pytest.skip("Java test server does not support worker versioning")

and ignore the versioning part.

[Sushisource]

I mean it shouldn't need to be skipped at all, the propagation of this data should also work on test server

[cretz]

🤷 Something else is breaking CI before it even gets to time-skipping now, unsure what, I can debug if necessary

[Sushisource]

Yeah, I don't know what's up with that. It's the test I wrote back when I added update but it was working perfectly fine but seems consistently broken here, but nothing here should affect it... (and it runs fine locally)

[Sushisource]

Huh, weird. I did manage to repro it once locally. I think it just flakes very rarely. Looks like there might be some race where occasionally the update handler is not registered on the first task. I'm not totally sure how that could be.

[cretz]

I agree, something confusing is happening here. From the code, surely the start workflow task should run before the update attempt. I can't see from the code how that could be either. I wonder in the case where you repro if somehow the activation has the update before the start?

I do think it's quite an important find and I think we should definitely dig into it, but I understand if you don't want it holding this up. You can either open an issue and skip the test (or that part at least), or feel free to investigate inline if you don't mind it holding this up. I was gonna ask internally whether there was any known issue where an update event coming before a start event on the server, but then I recall it's actually sent as a "protocol". So I wonder if that protocol event interleaving code either has a random issue putting it before start in the activation, or the event sequencing number put on the protocol message is wrong from the server side. I wonder if we can repro more easily by not starting the worker until after we've sent the update ensuring that start and update are in the same activation.

[cretz]

Ok, we figured this out. We intentionally order updates before start, so in the case where your client command start-then-updates before the task is delivered, update will run first. And we don't have a buffer-update-for-life-of-task like Go, Java, and TS do. We will discuss internally, but in the meantime this test is a bit flawed in assuming updates always come after start. Can fix now, or skip that assertion and open issue (we're probably going to have to open an issue anyways).