Documentation
¶
Index ¶
- func GetReposFromContext(ctx context.Context) (domain.RepoFactory, bool)
- func NewOutboxBillingPublisher() domain.BillingPublisher
- func NewOutboxHubspotSyncPublisher() domain.HubspotSyncPublisher
- func NewOutboxNotificationPublisher() domain.NotificationPublisher
- func NewOutboxProductionScheduleEnqueuer() domain.ProductionScheduleEnqueuer
- func NewOutboxSalesOrderEventPublisher() domain.SalesOrderEventPublisher
- func WithRepos(ctx context.Context, repos domain.RepoFactory) context.Context
- type BatchScannedConsumer
- type BulkOperationConsumer
- type BulkOperationExecutor
- type CustomerRegisteredPublisher
- type ExecuteProductionStepConsumer
- type ExportConsumer
- type ExportRenderer
- type GenerateProductionScheduleConsumer
- type HubspotSyncConsumer
- type InventoryReceivedConsumer
- type ItemCostBasisChangedConsumer
- type PurgeAccountDataPayload
- type PurgeConsumer
- type RecalcItemBurnRateConsumer
- type SalesOrderCreatedConsumer
- type SalesOrderShippingUpdatedConsumer
- type SeedConsumer
- type SeedSandboxPayload
- type SyncStripeCustomerConsumer
- type UndoBatchScanConsumer
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func GetReposFromContext ¶
func GetReposFromContext(ctx context.Context) (domain.RepoFactory, bool)
GetReposFromContext retrieves the RepoFactory from the context.
func NewOutboxBillingPublisher ¶
func NewOutboxBillingPublisher() domain.BillingPublisher
NewOutboxBillingPublisher creates a billing publisher that writes to the outbox table for reliable message delivery.
func NewOutboxHubspotSyncPublisher ¶
func NewOutboxHubspotSyncPublisher() domain.HubspotSyncPublisher
NewOutboxHubspotSyncPublisher creates a HubSpot sync command publisher that writes to the outbox table for reliable delivery.
func NewOutboxNotificationPublisher ¶
func NewOutboxNotificationPublisher() domain.NotificationPublisher
NewOutboxNotificationPublisher creates a notification publisher that writes to the outbox table for reliable message delivery.
func NewOutboxProductionScheduleEnqueuer ¶
func NewOutboxProductionScheduleEnqueuer() domain.ProductionScheduleEnqueuer
func NewOutboxSalesOrderEventPublisher ¶
func NewOutboxSalesOrderEventPublisher() domain.SalesOrderEventPublisher
NewOutboxSalesOrderEventPublisher creates a sales-order event publisher that writes to the outbox table for reliable message delivery.
Types ¶
type BatchScannedConsumer ¶
type BatchScannedConsumer struct {
// contains filtered or unexported fields
}
BatchScannedConsumer moves inventory in reaction to a scan: it credits what the batch produced, releases the reservations covering units that seconds and waste mean will never exist, and draws down the materials the step consumed.
It is one subscriber to core.event.batch_scanned among however many the account eventually wants; it owns no part of the event beyond deciding what inventory should do about it.
The whole reaction commits as one transaction. The delivery is retried with backoff and replayed from the top on failure, and none of these writes is individually idempotent — a step that failed after allocating drew the same receipts again on the retry, consuming stock that never moved.
func NewBatchScannedConsumer ¶
func NewBatchScannedConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, repos domain.RepoFactory, txManager db.TransactionManager[*sqlc.Queries, domain.RepoFactory], ) *BatchScannedConsumer
func (*BatchScannedConsumer) Listen ¶
func (c *BatchScannedConsumer) Listen(ctx context.Context) error
func (*BatchScannedConsumer) ReplayMessage ¶ added in v1.1.11
ReplayMessage re-drives a single delivery through the same inbox-dedup wrapper Listen uses, so a maintenance tool can re-run a message that failed permanently without re-applying one that already succeeded: the wrapper skips any inbox record already marked processed.
type BulkOperationConsumer ¶
type BulkOperationConsumer struct {
// contains filtered or unexported fields
}
BulkOperationConsumer is the single consumer behind every async bulk operation. Each bulk endpoint enqueues a {job_id} command; this consumer loads the job (whose resolved, validated payload was stored at enqueue time), restores the originating identity, and hands off to the entity's executor. The only variance between operations is data — the queue, the inbox handler key, and the executor — so there is one implementation instead of one near-identical file per operation. The message inbox de-dupes redeliveries so retries converge on one visible outcome.
func NewBulkOperationConsumer ¶
func NewBulkOperationConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, op messaging.BulkOperation, execute BulkOperationExecutor, ) *BulkOperationConsumer
builds the consumer for one bulk operation, pairing the operation's canonical identity with the entity service's Execute method
type BulkOperationExecutor ¶
BulkOperationExecutor performs the write phase of an enqueued bulk operation: it loads the job named by the event and runs its resolved rows. Each entity's service supplies one — its Execute method value (e.g. unitGroupSvc.ExecuteBulkUpsertUnitGroups).
type CustomerRegisteredPublisher ¶
type CustomerRegisteredPublisher struct{}
CustomerRegisteredPublisher writes customer-registered events to the outbox so the notification-service can notify the seller's customer-service group out-of-band from the registration response.
func NewCustomerRegisteredPublisher ¶
func NewCustomerRegisteredPublisher() *CustomerRegisteredPublisher
NewCustomerRegisteredPublisher creates a publisher for customer-registered events.
func (*CustomerRegisteredPublisher) Publish ¶
func (p *CustomerRegisteredPublisher) Publish(ctx context.Context, outboxRepo messaging.OutboxRepo, data messaging.CustomerRegisteredData) *apierror.APIError
Publish enqueues a customer-registered event via the outbox. It is safe to call inside a service transaction: the outboxRepo write commits atomically with the registration mutation.
type ExecuteProductionStepConsumer ¶
type ExecuteProductionStepConsumer struct {
// contains filtered or unexported fields
}
ExecuteProductionStepConsumer processes execute-production-step commands. It calculates inventory changes from batch mutations (initialize, move, merge, split) and creates inventory receipts/issues accordingly.
func NewExecuteProductionStepConsumer ¶
func NewExecuteProductionStepConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, queries *sqlc.Queries, repos domain.RepoFactory, txManager db.TransactionManager[*sqlc.Queries, domain.RepoFactory], ) *ExecuteProductionStepConsumer
type ExportConsumer ¶
type ExportConsumer struct {
// contains filtered or unexported fields
}
consumes one export command. An export carries the same {job_id} payload a bulk operation does, so the shape mirrors BulkOperationConsumer; only the work differs.
func NewExportConsumer ¶
func NewExportConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, op messaging.ExportOperation, render ExportRenderer, ) *ExportConsumer
builds the consumer for one export, pairing its canonical identity with the service method that renders and uploads the file
type ExportRenderer ¶
renders an accepted export and settles the job tracking it. Each entity's service supplies one — its BuildExport method value.
type GenerateProductionScheduleConsumer ¶
type GenerateProductionScheduleConsumer struct {
// contains filtered or unexported fields
}
GenerateProductionScheduleConsumer runs the solve the generation cadence queued.
The solve lives here rather than in the cadence tick because it takes minutes on a real tenant: running it inside the scheduler lease would block every other account behind whichever one is currently solving.
func NewGenerateProductionScheduleConsumer ¶
func NewGenerateProductionScheduleConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, scheduleSvc domain.ProductionScheduleSvc, repos domain.RepoFactory, ) *GenerateProductionScheduleConsumer
type HubspotSyncConsumer ¶
type HubspotSyncConsumer struct {
// contains filtered or unexported fields
}
HubspotSyncConsumer runs the long-running HubSpot backfill passes (preview and execute) out-of-band. The queue is bound to both command routing keys; handleMessage dispatches on the routing key.
func NewHubspotSyncConsumer ¶
func NewHubspotSyncConsumer(rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, hubspotSync hubspotsync.Service) *HubspotSyncConsumer
type InventoryReceivedConsumer ¶
type InventoryReceivedConsumer struct {
// contains filtered or unexported fields
}
InventoryReceivedConsumer offers newly available stock to the demand that went short waiting for it.
An issue goes open when it was asked for more than the shelf could cover. It stays short until stock arrives, and this is what notices that it has. That used to be a nightly sweep over every open issue in the account, which meant an order could sit unfilled for most of a day with the stock to fill it already on the floor — and made a scan that failed to allocate indistinguishable from one that had nothing to allocate, because the sweep quietly fixed both.
func NewInventoryReceivedConsumer ¶
func NewInventoryReceivedConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, repos domain.RepoFactory, txManager db.TransactionManager[*sqlc.Queries, domain.RepoFactory], ) *InventoryReceivedConsumer
type ItemCostBasisChangedConsumer ¶
type ItemCostBasisChangedConsumer struct {
// contains filtered or unexported fields
}
ItemCostBasisChangedConsumer recomputes the cost of everything downstream of a change.
A cost is only as current as the inputs it was last calculated from, so moving a material's price or editing a production step leaves every part and product built on it stale. This walks the production graph outwards from the change and recalculates what it reaches.
It replaces a nightly job that recomputed every item with a production, for one hardcoded account, whether or not anything had changed — which meant a price change entered on Tuesday was wrong on every quote until Wednesday morning, and right by accident rather than by design.
func NewItemCostBasisChangedConsumer ¶
func NewItemCostBasisChangedConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, repos domain.RepoFactory, itemSvc domain.ItemSvc, ) *ItemCostBasisChangedConsumer
type PurgeAccountDataPayload ¶
type PurgeAccountDataPayload struct {
AccountID string `json:"account_id"`
}
PurgeAccountDataPayload is the payload for CoreCmdPurgeAccountData messages.
type PurgeConsumer ¶
type PurgeConsumer struct {
// contains filtered or unexported fields
}
func NewPurgeConsumer ¶
func NewPurgeConsumer(rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, purgeRepo *repository.PurgeRepo) *PurgeConsumer
type RecalcItemBurnRateConsumer ¶ added in v1.1.8
type RecalcItemBurnRateConsumer struct {
// contains filtered or unexported fields
}
RecalcItemBurnRateConsumer recomputes an item's burn rate from its recent consumption history, off the transaction that recorded the consumption. That transaction is long, and recomputing inline held the shared rate row's X-lock for its whole length; doing it here holds that lock only for this consumer's own short transaction.
The command carries only the item's identity and the rate is recomputed from current state, so repeated commands coalesce and a redelivery recomputes the same absolute value.
func NewRecalcItemBurnRateConsumer ¶ added in v1.1.8
func NewRecalcItemBurnRateConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, repos domain.RepoFactory, txManager db.TransactionManager[*sqlc.Queries, domain.RepoFactory], ) *RecalcItemBurnRateConsumer
type SalesOrderCreatedConsumer ¶
type SalesOrderCreatedConsumer struct {
// contains filtered or unexported fields
}
SalesOrderCreatedConsumer processes sales-order-created events and runs the out-of-band side effects that should not block the create response — dispatching CRM sync for accounts with a connected integration (e.g. HubSpot), and warming the carrier transit estimate for the order's lane.
func NewSalesOrderCreatedConsumer ¶
func NewSalesOrderCreatedConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, hubspotSync hubspotsync.Service, transitWarmer domain.TransitWarmer, ) *SalesOrderCreatedConsumer
type SalesOrderShippingUpdatedConsumer ¶
type SalesOrderShippingUpdatedConsumer struct {
// contains filtered or unexported fields
}
SalesOrderShippingUpdatedConsumer re-syncs an order's existing shipment records (carrier / service level / ship-to) after the order's shipping fields changed, out-of-band from the update response. This mirrors legacy updateCarrierByOrder / updateShipToByOrder, which cascaded these edits to shipments synchronously.
func NewSalesOrderShippingUpdatedConsumer ¶
func NewSalesOrderShippingUpdatedConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, repos domain.RepoFactory, transitWarmer domain.TransitWarmer, ) *SalesOrderShippingUpdatedConsumer
type SeedConsumer ¶
type SeedConsumer struct {
// contains filtered or unexported fields
}
func NewSeedConsumer ¶
func NewSeedConsumer(rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, seeder *repository.SandboxSeeder) *SeedConsumer
type SeedSandboxPayload ¶
type SeedSandboxPayload struct {
AccountID string `json:"account_id"`
}
SeedSandboxPayload is the payload for CoreCmdSeedSandbox messages.
type SyncStripeCustomerConsumer ¶
type SyncStripeCustomerConsumer struct {
// contains filtered or unexported fields
}
SyncStripeCustomerConsumer mirrors a customer create/update onto the account's connected Stripe integration.
The mutation itself already committed — this is Stripe catching up behind it. Running out-of-band is what keeps a Stripe outage from failing a customer edit that has nothing to do with payments.
func NewSyncStripeCustomerConsumer ¶
func NewSyncStripeCustomerConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, stripeSync stripesync.Service, ) *SyncStripeCustomerConsumer
type UndoBatchScanConsumer ¶
type UndoBatchScanConsumer struct {
// contains filtered or unexported fields
}
UndoBatchScanConsumer reverses the inventory a scan recorded against a batch that has been deleted: the receipts it produced, the issues it consumed, and the reservations it drew down.
The delete itself already happened synchronously — this is the ledger catching up behind it, the mirror of ExecuteProductionStepConsumer running behind a scan.
func NewUndoBatchScanConsumer ¶
func NewUndoBatchScanConsumer( rabbitmq messaging.MessageBroker, inboxRepo messaging.InboxRepo, repos domain.RepoFactory, ) *UndoBatchScanConsumer
Source Files
¶
- batch_scanned_consumer.go
- billing_publisher.go
- bulk_operation_consumer.go
- customer_registered_publisher.go
- execute_production_step_consumer.go
- export_consumer.go
- generate_production_schedule_consumer.go
- hubspot_sync_consumer.go
- hubspot_sync_publisher.go
- inventory_audit.go
- inventory_received_consumer.go
- item_cost_basis_changed_consumer.go
- notification_publisher.go
- production_schedule_enqueuer.go
- purge_consumer.go
- recalc_item_burn_rate_consumer.go
- sales_order_created_consumer.go
- sales_order_event_publisher.go
- sales_order_shipping_updated_consumer.go
- seed_consumer.go
- sync_stripe_customer_consumer.go
- types.go
- undo_batch_scan_consumer.go