(question) Jest jakiś powód, dla którego używasz tutaj params.field_name, a poniżej samego field_name?

(should) Na wszelki wypadek można tu zmienić == na ===

(question) Czemu służy ta linia? :P

(question) Czy czasem nie chciałeś użyć tutaj zmiennej COLLECTION_NAME, a nie stringa? :P

Wtrącę swoje 3 grosze, że rzeczywiście to co mówi Arkadiusz, to jest dobra praktyka - uniezależniamy się od reprezentacji stanu, natomiast w tym wypadku, jak to jest 7 przypisań w 2 plikach i jest to fajnie przesłonięte w testach, to na razie bym nie zmieniał. Jak się zacznie rozrastać, to rzeczywiście warto

(question)

Wiem, że to przyszło w ramach innego taska, ale czy na pewno to jest dobra praktyka? Czy aplikacja powinna zdradzać, że dane konto nie istnieje?

(should)
Może to opinionated, ale kocham redukcję nestingu (tak zresztą sam zrobiłeś w następnej funkcji) - sugeruję odwrócenie warunku w ifie, wtedy ten pojedynczy return powędruje na początek a reszta nie będzie musiała być w else

(could) Znowu jest miejsce na redukcję nestingu - jeżeli format_params[0] nie przyjmuje żadnej z wartości oraz może, dla spójności, zamiast return undefined zrobić return decoded_value.

(could)
Mimo wszystko parseInt bez drugiego argumentu napełnia mnie niepokojem ;)

(could) A może const bs = await Promise.map(...) i wyleci for?

Nieznałem tego - fajne!

(should) Ten fragment:

await with_stopped_app(async ({ app, rest_api }) => {
     await create_referencing_collections(app, "with_reverse" && true);
     await app.start();
     await create_resources(app);})

powtarza się w każdym teście - moim zdaniem można to łatwo wyłączyć do osobnej funkcji przyjmującej parametr with_reverse

(question) Dlaczego 3?

(could)

Skoro się powtarza w try i catch to dobry przypadek użycia sekcji finally