Add examples to the project#277
Conversation
| import type { CommonEventDefinition } from '../events/eventTypes.ts' | ||
|
|
||
| export type SnsAwareEventDefinition = { | ||
| schemaVersion?: string |
| * Resolves schema of all possible publisher messages for a given list of event definitions | ||
| */ | ||
| export type allPublisherMessageSchemas<MessageDefinitionTypes extends CommonEventDefinition[]> = | ||
| export type AllPublisherMessageSchemas<MessageDefinitionTypes extends CommonEventDefinition[]> = |
| export type CommonEventDefinition = { | ||
| consumerSchema: ZodObject< | ||
| Omit<(typeof CONSUMER_BASE_EVENT_SCHEMA)['shape'], 'payload'> & { | ||
| Omit<(typeof CONSUMER_BASE_EVENT_SCHEMA)['shape'], 'payload' | 'metadata'> & { |
There was a problem hiding this comment.
ensuring that metadata here and in baseMessageSchema come from the same place make IDE much happier about infering types for whatever reason
| import type { CommonEventDefinition } from '@message-queue-toolkit/schemas' | ||
| import { z } from 'zod' | ||
|
|
||
| type AllConsumerMessageSchemas<MessageDefinitionTypes extends CommonEventDefinition[]> = z.infer< |
There was a problem hiding this comment.
will switch to the one from the library after it is released
| '@message-queue-toolkit/sns', | ||
| '@message-queue-toolkit/sqs' | ||
| ] | ||
| fail-fast: false |
There was a problem hiding this comment.
Do we want to execute all actions even when there is already one failing? Having it enabled is useful to save resources, but no strong opinion here
| export function userUpdatedHandler( | ||
| message: z.infer<typeof UserEvents.updated.consumerSchema>, | ||
| ): Promise<Either<'retryLater', 'success'>> { | ||
| _latestData = message.payload | ||
|
|
||
| return Promise.resolve({ result: 'success' }) | ||
| } |
There was a problem hiding this comment.
Do not have to be in this PR, but would be nice to show how to use barrier pattern and pre-handlers
| watch: false, | ||
| restoreMocks: true, | ||
| pool: 'threads', | ||
| poolOptions: { | ||
| threads: { singleThread: true }, | ||
| }, |
There was a problem hiding this comment.
I'm not sure if I'm reading it correctly, but to confirm, are we moving amqp/vitest.config to the new examples? is this intentional?
There was a problem hiding this comment.
see the suddenly flaky RabbitMQ tests (despite no changes in this PR)
happy to remove after it goes away
2 participants
No description provided.