Matthew Meszaros ec4cd3160b feat: thread Unibox dashboard replies into the conversation they answer, by carrying the composer's thread_id all the way from email_tasks to the provider (EmailMessage had no ThreadID field at all, so the column was read from the database and silently dropped in user_email_task, and Gmail only appends to an existing thread when threadId is set on the outbound message since a matching Subject and In-Reply-To do not do it), populating the models.SendEmail.Parent field that already existed with an avro tag and that the worker already read but nothing ever set, replacing the worker's gate that required InReplyTo to be non-empty before it would look at Parent (a dashboard reply never sets that header, so a perfectly valid ThreadID was discarded and the provider opened a new conversation) with a parentReference helper shared by the Gmail and Graph send paths that resolves the two genuinely independent handles separately, and backfilling the RFC In-Reply-To header server-side in UniboxReply from the newest Message-ID in the thread via a new org-scoped LatestMessageIDInThread query, because a provider thread id is meaningless outside the mailbox that issued it and the recipient's mail client can only thread on References and In-Reply-To (#122)

2026-08-16 07:46:16 +02:00

..

proto

ci: regenerate tasks.pb.go with protoc 33.6 to match CI installer

2026-05-23 17:10:40 +00:00

ai_variables.go

feat: resolve per-recipient AI variables in the campaign task before tracking, threading surrounding email context and caching results per contact and step

2026-07-22 17:05:08 +02:00

campaign_reconciler.go

feat: make scheduled sending self-healing - dispatch Cloud Tasks callbacks by the task row type (all enqueues share one webhook URL, so campaign callbacks were run through the warmup handler), cancel pending tasks stranded past their slot so the reconcilers re-seed chains after a lost callback or emulator restart, and cast the status enum in the two UPDATE ... CASE queries that failed parameter type deduction on every callback

2026-07-11 17:31:23 +02:00

campaign_task.go

feat: resolve per-recipient AI variables in the campaign task before tracking, threading surrounding email context and caching results per contact and step

2026-07-22 17:05:08 +02:00

content_lint.go

feat: add warmup content controls

2026-06-03 05:05:53 +02:00

dispatch.go

feat: make the inbound mail pipeline work end to end by never publishing the eventbus partition key as Nats-Msg-Id (JetStream deduped every event after the first per mailbox), fetching IMAP message bodies after the outer FETCH closes instead of nesting one inside it (which deadlocked sync on the first message), wrapping NEW_EMAIL in JobEventNewEmail across all three providers so the consumer stops nil-derefing, coalescing nil arrays before the NOT NULL unibox columns, sealing validation credentials on a copy so stored SMTP/IMAP passwords are not double encrypted, routing the email task type to the user email handler, and returning false instead of closing a nil conn in VerifySMTP (#88)

2026-07-31 09:41:36 +02:00

email_sender.go

feat: thread Unibox dashboard replies into the conversation they answer, by carrying the composer's thread_id all the way from email_tasks to the provider (EmailMessage had no ThreadID field at all, so the column was read from the database and silently dropped in user_email_task, and Gmail only appends to an existing thread when threadId is set on the outbound message since a matching Subject and In-Reply-To do not do it), populating the models.SendEmail.Parent field that already existed with an avro tag and that the worker already read but nothing ever set, replacing the worker's gate that required InReplyTo to be non-empty before it would look at Parent (a dashboard reply never sets that header, so a perfectly valid ThreadID was discarded and the provider opened a new conversation) with a parentReference helper shared by the Gmail and Graph send paths that resolves the two genuinely independent handles separately, and backfilling the RFC In-Reply-To header server-side in UniboxReply from the newest Message-ID in the thread via a new org-scoped LatestMessageIDInThread query, because a provider thread id is meaningless outside the mailbox that issued it and the recipient's mail client can only thread on References and In-Reply-To (#122)

2026-08-16 07:46:16 +02:00

email_task.go

feat: automate warmup conversation generation, coherent replies, adaptive rotation, and admin observability

2026-07-22 12:11:19 +02:00

handler.go

New Repository: Add Backend Code

2026-01-17 14:11:14 +00:00

partner_selection_test.go

feat: customer-defined warmup routing rules on premium pool

2026-05-25 15:42:50 +00:00

service.go

feat: resolve per-recipient AI variables in the campaign task before tracking, threading surrounding email context and caching results per contact and step

2026-07-22 17:05:08 +02:00

spintax.go

feat: preview campaign templates

2026-06-08 15:04:53 +02:00

switch_step.go

feat: rework automation AI steps to mirror campaign step types with one agentic AI step plus an AI switch, per-case switch handles on the canvas, a Stop node, and a step-type add menu

2026-07-22 10:58:35 +02:00

template_test.go

feat: add campaign workflow backend support

2026-06-06 07:49:52 +02:00

template.go

feat: automate warmup conversation generation, coherent replies, adaptive rotation, and admin observability

2026-07-22 12:11:19 +02:00

test_email.go

feat: seal outbound email content with the organization DEK

2026-06-10 17:16:42 +02:00

user_email_task.go

feat: thread Unibox dashboard replies into the conversation they answer, by carrying the composer's thread_id all the way from email_tasks to the provider (EmailMessage had no ThreadID field at all, so the column was read from the database and silently dropped in user_email_task, and Gmail only appends to an existing thread when threadId is set on the outbound message since a matching Subject and In-Reply-To do not do it), populating the models.SendEmail.Parent field that already existed with an avro tag and that the worker already read but nothing ever set, replacing the worker's gate that required InReplyTo to be non-empty before it would look at Parent (a dashboard reply never sets that header, so a perfectly valid ThreadID was discarded and the provider opened a new conversation) with a parentReference helper shared by the Gmail and Graph send paths that resolves the two genuinely independent handles separately, and backfilling the RFC In-Reply-To header server-side in UniboxReply from the newest Message-ID in the thread via a new org-scoped LatestMessageIDInThread query, because a provider thread id is meaningless outside the mailbox that issued it and the recipient's mail client can only thread on References and In-Reply-To (#122)

2026-08-16 07:46:16 +02:00

warmup_content.go

feat: automate warmup conversation generation, coherent replies, adaptive rotation, and admin observability

2026-07-22 12:11:19 +02:00

warmup_reconciler.go

feat: make scheduled sending self-healing - dispatch Cloud Tasks callbacks by the task row type (all enqueues share one webhook URL, so campaign callbacks were run through the warmup handler), cancel pending tasks stranded past their slot so the reconcilers re-seed chains after a lost callback or emulator restart, and cast the status enum in the two UPDATE ... CASE queries that failed parameter type deduction on every callback

2026-07-11 17:31:23 +02:00