Floci: write the contract your local cloud test can prove

A worker receives a queue message, writes the result, then crashes before deleting the message. A useful local test makes the next delivery visible and checks whether the application repeats the side effect. A successful create-queue request tells us much less about that failure.

That is the test I would bring to Floci, an open-source AWS emulator. This is a source review checked on November 6, 2026. I read its documentation and code configuration; I did not install it, run an AWS comparison or measure its performance. The proposed workflow below is analysis, not a reported experiment.

Read the service row closely

The repository describes two broad implementation paths. Some services run in process. Others use real Docker containers for runtimes, databases or protocols. Its coverage table distinguishes these paths: SQS is part of the local service surface, while RDS and Lambda have Docker-backed execution. The documentation also identifies approximations. Its Aurora DSQL row says the PostgreSQL-backed implementation does not yet reproduce DSQL's limits and asynchronous indexes.

This is useful disclosure. A real database engine can exercise SQL and driver behavior while leaving a managed service's control plane only partly represented. My inference is that a coverage list should become a list of questions about the application's actual calls. The presence of a service name cannot answer those questions on its own.

Start with one workflow: send a synthetic message, receive it, write a synthetic record, acknowledge the delivery. Record which queue operations and attributes that workflow needs. A narrower contract gives a team something it can inspect when an emulator update changes behavior. A broad claim such as "the cloud tests passed" loses the distinction between the paths actually exercised and everything else in the service table.

Keep local endpoints deliberate

The SDK examples point clients at http://localhost:4566 with synthetic credentials. I would make that endpoint an explicit input to a local test rather than inherit an ambient production profile. The small guard below is an original explanatory example. It does not start an emulator, call a cloud service, prove network isolation or configure a queue.

from urllib.parse import urlsplit

def require_local_endpoint(endpoint):
    u = urlsplit(endpoint)
    if (u.scheme != "http" or u.hostname != "127.0.0.1"
            or u.port != 4566 or u.username or u.password
            or u.path not in ("", "/") or u.query or u.fragment):
        raise ValueError("Expected the explicit loopback test endpoint")
    return endpoint

endpoint = require_local_endpoint("http://127.0.0.1:4566")
# Pass endpoint and synthetic credentials explicitly to the test client.

The restriction is intentionally narrow. It rejects containers reached through a different hostname and does not replace firewall rules. A containerized test needs its own reviewed network configuration. The important implementation choice is to fail closed when the intended target is missing, rather than silently fall back to a real account. Keep production data and credentials out of this workflow.

Choose the failure before choosing the assertion

For the queue example, I would test these cases separately: normal acknowledgement; a consumer crash before acknowledgement; a repeated application-level message identifier; an invalid request; a forbidden operation with enforcement configured. Those are proposed tests, not claims about which cases Floci passes. Each case needs an expected observable result, a timeout and an application-level side-effect count.

Synthetic message → local queue → consumer → synthetic result
                                      |
                               crash before delete
                                      |
                              observe redelivery
                                      |
                          count application side effects

Selected contract → separate authorized AWS comparison

For example, the application may require one stored result per business identifier even after repeated deliveries. The assertion should inspect that stored result, not only whether the worker returned a zero exit status. Keep the receipt handle and the business identifier conceptually separate. A test that simply runs the happy path twice may never exercise a crash between the write and the acknowledgement.

Defaults can hide the permission test

The multi-account documentation says twelve-digit access key IDs select account namespaces. Other formats fall back to the configured default account. It also states that signature verification is off by default. The environment-variable reference lists IAM policy enforcement as disabled by default.

Those defaults make local development convenient. They also change what a passing test means. Account routing, signature checking and policy enforcement are separate claims. Two synthetic accounts that cannot see each other's resources do not establish that a forged signature or forbidden action was rejected. A permission test must record the enabled checks and include a refusal case. I would retain that configuration beside the test result.

State and host access belong in the test plan

The storage guide distinguishes memory, persistent, hybrid and write-ahead-log modes. The README describes memory as losing state when the container stops, immediate writes for persistent mode, periodic flushing for hybrid mode and logging mutations before responses for WAL. These are documented implementation choices, not an independently reproduced durability result.

A test that needs a clean queue should choose that lifecycle deliberately. A recovery test should define the restart boundary and inspect the resulting data. Docker-backed features introduce another boundary: the README requires access to the Docker socket for those paths. I would start a simple in-process test without that mount and grant host-container control only when the selected workflow needs it, in a disposable environment.

My selection rule

Floci's MIT license permits reuse under its notice requirements and disclaims warranty. Repository activity was visible on November 5. Neither fact proves fidelity. Pin the reviewed revision or release, keep a behavior matrix, and reserve a separate, explicitly authorized AWS check for the semantics that matter before release. Any cloud comparison has its own costs and cleanup obligations. I would adopt an emulator for the feedback it can demonstrate, with the untested boundaries written next to the green result.