# 02 — The readers

How a secret reaches a running process, and what makes the process take a new one.

## No module watches a secret

A search of every module's code in the catalogue found no file watching of any kind, and no
re-reading of a secret while running. **Every reader reads a secret when it starts.** There is no
consumer that takes a new value live, so every rotation that changes what a consumer presents ends in
the consumer restarting.

## The host already recreates what read a changed file

The node host records, for every long-running container, the digest of each file it read when it
was created: its env-files, and every file bind-mounted into it directly. When a digest changes, the
host recreates the container, even though its spec is otherwise unchanged. This is the fix for
[issue 103](../../04-ISSUES/103-a-container-is-not-recreated-when-a-file-it-reads-changes/00-report.md).
It is on the host's main branch, while the issue is still recorded as located, not fixed.

Two cases are deliberately left out and need `restart-on` in the definition:

- a file read out of a **mounted directory**, because the host cannot know whether the service reads
  it once or watches it (a route proxy re-reads its routes live; a provisioner polls what it receives);
- a **process** rather than a container.

## What the catalogue does with it

22 definitions declare a secret they receive. In 16 of them it reaches the service through a
rendered file, usually an env-file. That case the host already covers. 14 declare `restart-on` for
something. Whether each of the 22 is fully covered depends on how its secret travels: through an
env-file or a direct mount, which the host covers, or through a directory or into a process, which
needs `restart-on`. **That was not classified module by module.** It is the check to run before a
rotation mechanism relies on it.

## What this means for rotation

- The *read at start* half of 0113's recipient model is already true, and mostly already handled by
  the host. The restart is derived from the files a container reads, not declared per secret.
- Any mechanism, in place or overlapping, ends with the reader being recreated. What differs is
  whether the credential it held until then still works.
- For a single-party secret, a module's own, the reader is also the only holder. There is nobody to
  overlap with, and delivering the new file recreates the reader.