refactor: check payload type before extracting assistant thread info

[zimeg]

Summary

This PR checks the payload type before extracting assistant thread info. Hopes to fix recent CI errors in #2601 and on main 👾

Error: src/Assistant.ts(398,21): error TS18048: 'payload.assistant_thread' is possibly 'undefined'.
Error: src/Assistant.ts(401,5): error TS2322: Type 'unknown' is not assignable to type 'string'.
Error: src/Assistant.ts(402,5): error TS2322: Type 'unknown' is not assignable to type 'string'.
Error: src/Assistant.ts(403,5): error TS2322: Type 'unknown' is not assignable to type 'AssistantThreadContext'.

Notes

• I'm not finding the same error on my machine a matching typescript version as ci: output verbose details when installing packages for tests #2602 👁️‍🗨️
• No change to functionality! Tests remain the same:

bolt-js/test/unit/Assistant.spec.ts

Lines 252 to 298 in 3948ded

	describe('extractThreadInfo', () => {
	it('should return expected channelId, threadTs, and context for `assistant_thread_started` event', async () => {
	const mockThreadStartedArgs = wrapMiddleware(createDummyAssistantThreadStartedEventMiddlewareArgs());
	const { payload } = mockThreadStartedArgs;
	const { extractThreadInfo } = await importAssistant();
	const { channelId, threadTs, context } = extractThreadInfo(payload);
	assert.equal(payload.assistant_thread.channel_id, channelId);
	assert.equal(payload.assistant_thread.thread_ts, threadTs);
	assert.deepEqual(payload.assistant_thread.context, context);
	});
	it('should return expected channelId, threadTs, and context for `assistant_thread_context_changed` event', async () => {
	const mockThreadContextChangedArgs = wrapMiddleware(
	createDummyAssistantThreadContextChangedEventMiddlewareArgs(),
	);
	const { payload } = mockThreadContextChangedArgs;
	const { extractThreadInfo } = await importAssistant();
	const { channelId, threadTs, context } = extractThreadInfo(payload);
	assert.equal(payload.assistant_thread.channel_id, channelId);
	assert.equal(payload.assistant_thread.thread_ts, threadTs);
	assert.deepEqual(payload.assistant_thread.context, context);
	});
	it('should return expected channelId and threadTs for `message` event', async () => {
	const mockUserMessageArgs = wrapMiddleware(createDummyAssistantUserMessageEventMiddlewareArgs());
	const { payload } = mockUserMessageArgs;
	const { extractThreadInfo } = await importAssistant();
	const { channelId, threadTs, context } = extractThreadInfo(payload);
	assert.equal(payload.channel, channelId);
	// @ts-expect-error TODO: AssistantUserMessageMiddlewareArgs extends from too broad of a message event type, which contains types that explicitly DO NOT have a thread_ts. this is at odds with the expectation around assistant user message events.
	assert.equal(payload.thread_ts, threadTs);
	assert.isEmpty(context);
	});
	it('should throw error if `channel_id` or `thread_ts` are missing', async () => {
	const { payload } = wrapMiddleware(createDummyAssistantThreadStartedEventMiddlewareArgs());
	payload.assistant_thread.channel_id = '';
	const { extractThreadInfo } = await importAssistant();
	const extractThreadInfoFn = () => extractThreadInfo(payload);
	const expectedMsg = 'Assistant message event is missing required properties: channel_id';
	assert.throws(extractThreadInfoFn, AssistantMissingPropertyError, expectedMsg);
	});
	});

Requirements

• I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Please upload report for BASE (main@3948ded). Learn more about missing BASE report.
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2603   +/-   ##
=======================================
  Coverage        ?   93.37%           
=======================================
  Files           ?       37           
  Lines           ?     7581           
  Branches        ?      667           
=======================================
  Hits            ?     7079           
  Misses          ?      497           
  Partials        ?        5           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[WilliamBergamin]

Thank you for addressing this 🙏

Comparing this with the Bolt Python implementation AssistantUtilities and has_channel_id_and_thread_ts, I fear this may be creating a drift between the implementations 🤔 I'm not sure which one is correct, what do you think about mirroring the logic and adding what is needed to make it type compliant?

Let me know if I'm completely wrong on this, I'm not as up to speed on this as you are

[zimeg]

@WilliamBergamin I appreciate the pushback on the initial change here 🤖 ✨

The approach you linked is great for handling changes to the underlying event types! Some searching for the cause of these errors lead to this update to the message event from slackapi/node-slack-sdk#2077:

export interface GenericMessageEvent {
  type: 'message';
...
  assistant_thread?: Record<string, unknown>;
}

Commit 62de663 uses the initial approach while now guarding against unexpected properties of assistant_thread for these events 🙏

[zimeg]

@WilliamBergamin Praises once more for the callout in keeping implementations similar. I was not thinking so far ahead to added confusion of future changes 🧠💡

I'll merge this PR now to unblock tests, but I do also think a release is needed to fix unpinned installations with the recent release of the @slack/types@2.15.0 package 😓