Skip to content

Arch Forum 2025-08-14

Participants: Backend devs, Kyle, Magnus, Andy and Victor

Agenda

  • SQLFluff to format our SQL code
  • Cryptocurrency codes (USDC, etc.)
  • Non-open FluentAssertions 8.0
  • Flexible Enums

Summary

SQLFluff to format our SQL code

Today we have a formatter for C#, but it doesn't format SQL, even though we have a fair amount of T-SQL (mostly DDL & SP scripts). It seems reasonable to also have a formatter for SQL.

Victor has done some research and landed on SQLFluff, a tool that is already used by the data team.

An out-of-the-box example of SQLFluff-formatted SQL is in this PR: majority-dev/be-user!914

A short discussion followed:
- Majority is either positive about having automatic formatting or at least neutral
- The same reasons why we format the C# code naturally apply to the SQL code.
- If implemented it should work as the current C# formatter:
- Run in the pipeline, in the same step as the C# formatter
- Produce a single commit of all formatted code (regardless of whether it's C# or SQL)
- Only run on changed or new code
- Developers can choose whether they want to run it locally in addition to the pipeline. SQLFluff exists as a plugin for VS Code, and it can also run from the command line (it's possible to make a commit hook, for example)

Given the overall positive discussion, Victor will continue to work on this.

Cryptocurrency codes (USDC, etc.)

With Global Wallet/crypto, we will have USDC (or similar) cryptocurrency. They are not ISO 4217 currency codes. The details on how to handle this are unclear, but it's something we will need to decide on. For now, this was just to raise awareness across backend and gather any immediate feedback.

(Searching for char(3), which is the likely DB column size, gives ~340 hits, most of them currency codes.)

Non-open-source FluentAssertions 8.0

Earlier this summer, Vitaly raised concerns around FluentAssertions here: https://majority.slack.com/archives/CED0QVB0F/p1754301455510349. He has already unified backend to use the same version set in Platform, but the question about the non-open-source FluentAssertions remains.

Somewhat realistic alternatives (in order of effort):

Notes from the meeting:

  • It is useful to have an assertion helper library.
    • BeEquivalentTo is useful to compare complex objects
    • Assertions on collections and date/time values are also helpful

Given that we like the FluentAssertions helpers, the easiest way forward will be to migrate to AwesomeAssertions. When that will happen is a different question; right now, we are quite behind on the version and not yet affected by the license changes of FluentAssertions.

Another test library, AutoFixture, was mentioned by Martin in the meeting. Victor will discuss with Martin to see if there's anything easy to gain and, if so, bring it up again.

Flexible Enums

In Platform, we have two custom enum classes—the flexible enums. We should use them as much as possible, and below is a small motivation/overview of them.

The problem: Adding new fields to a normal enum requires all users to update before the new value is used. Otherwise users will crash if the new enum is included in a event, regardless of the property is read or not.

Recent example from slack:

We need to deploy all areas that consume KycSuccessfullyVerifiedEvent before global release as we have added a new enum to that event for global users, not deploying will cause serialization error when consuming those events

https://majority.slack.com/archives/CED0QVB0F/p1754993920413129?thread_ts=1754993642.728739&cid=CED0QVB0F

The solution:

Example usages in Transactions.Domain.Contract

Flexible enums:

  1. Handle new enum values without contract updates since they are "flexible".
  2. Serializable as a string, value, or full object.
  3. A potential downside is that it's less obvious that something has changed and that some areas need to handle it.

Victor will ensure we have something written on the wiki about how flexible enums work.