Arch Forum 2026-04-07

Participants: Backend devs, ??

Agenda

• The PR Template
• Recurring Scheduling in platform
• The be-template repo
• Single Deadletter queue
• Long running event handlers
• ValueObjects in platform

Summary

The PR Template

The old template had several issues:

• A checklist that has to be checked is easily "gamed", especially if an AI creates the PR
• The items in the checklist were not relevent in 90% of the cases
• The relevant items are better checked by other means (e.g. code coverage check)
• The checklist did not provide any useful value after PR created (neither the reviewer nor a future troubleshooter gained value from it)
• The checklist added friction to PRs, e.g. reviewer had to doublecheck and nag about checking the "useless" boxes

Requirements for a revised PR Template for the AI age.

• For compliance a template must exist and be used properly.
• It should be as minimal as possible, while still providing value.
• Its ok to require more effort than checking 5 boxes, the expectation is that an AI will fill it out most of the time.

The new template:

## Changes

<what changed>

## Validation

<how this was verified>

## Risks / Notes

<any impact, exceptions, or none>

(https://github.com/majority-dev/be-template/blob/master/template/.github/PULL_REQUEST_TEMPLATE.md)

Some examples:

• majority-dev/be-platform!367
• majority-dev/be-template!12

Recurring Scheduling in platform

See Scheduling.

Already live in be-auditing. Demo.

The be-template repo

Live on be-ach, be-accountstatements and be-transactions. If you create a new repo, make sure to use the template! Victor will slowly add all backend repos to use the template.

See Repo Template

Single Deadletter queue

To better handle RabbitMQ Deadletters (and in the future Auditing), we will move to a single Deadletter queue handling all:

Platform.DeadLetterQueue

Long running event handlers

In March PspFunding had two incidents were it stopped listening on Rabbit. This happened because of two problems:

1. The platform code could not always recover from channel shotdown, leaving the event processor in a bad state. (Fixed in platform)
2. PspFunding had extremely long running event handlers which made Rabbit regard the channel as broken and close it.

Two learnings:

1. An event handler must not run for too long:

• Long running handlers block the queue
• When the run time is too long rabbit will assume the event and channel is lost, and let other consumers handle the event.
• A good rule of thumb is to keep them as fast as http handlers, e.g. on the order of seconds, not minutes or longer.

2. Be careful when using a custom RetryPolicyConfigs setting:

The RetryDurationBetweenInSeconds field is exponetial despite its name. E.g. the wait between a retry is Math.Pow(RetryDurationBetweenInSeconds, retryAttempt) seconds.

ValueObjects in platform

In platform we have ValueObjects in the Majority.Platform/Rebtel.Core.Infrastructure.Shared.Contract package.

We also have a package called Minority.Core.Shared.Contract, with some additional (or duplicated) types.

The ValueObjects have never been used in a Contract before. Should they? (We had a quite sever bug in logging that made the application crash if a ValueObject was logged).