1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
//! Per-caller directory component failure and retry matrix.
use Path;
use crate;
use crateunique_temp_dir;
use cratematerialize_manifest_entries;
use crate::;
const COMPONENT_POINTS: = ;
// RFC 102 Stage 3: `object_directory_component_matrix` (proving a first-object-write directory
// component failure is retryable) has no container-era equivalent and was removed rather than
// retargeted. Every container and index file is allocated once, at `init`, per
// `layout/tests.rs::init_allocates_every_container_index_and_generation_log_name_once` -- an
// object write never creates a directory component at all anymore, so this matrix's own
// `DirectoryCreate`/`CreatedDirectoryParentSync` failpoints are simply never reached by
// `FileObjectStore::write_object`, and there is no analogous scenario left to prove here.
// RFC 102 Stage 5, design-v1.md §14.3/§14.5: `wal_directory_component_matrix` (proving a
// missing-directory-plus-missing-WAL-file failure during append was retryable) has no
// strict-`durable_append`-era equivalent, and was removed rather than retargeted -- the same
// disposition Stage 3 and Stage 4 gave the two retirement notes above, for the same underlying
// reason arriving through a third door. Its setup deleted `queue.wal` and then its now-empty
// parent directory to force what was then `wal.rs:194`'s defensive `ensure_directory_required`
// to recreate a directory from nothing; under the old lenient `durable_append`, the subsequent
// append also transparently recreated the deleted file. Strict `durable_append` closes exactly
// that transparent recreation (design-v1.md §14.3's own point: it "silently repairs" an
// interrupted-init-shaped state into an undetectable one), so the fixture's constructed state --
// directory absent, file absent -- is no longer one `wal.append_patch` can recover from, and is
// not a state a correctly-`init`ed repository can reach in the first place:
// `default_active_dir()` is in `required_directories()` (`layout.rs:378`) and nothing in this
// codebase ever removes a required directory. This was flagged as a finding rather than retired
// silently -- the same disposition Stage 3 and Stage 4 gave their own analogous calls -- and the
// dead-surface consolidation handoff (`rfcs/handoffs/consolidation/`) ruled it dead by the same
// reasoning and removed the `wal.rs` call outright.
// RFC 102 Stage 5, design-v1.md §14.8: `active_metadata_directory_component_matrix` (proving a
// missing-`active/default/`-directory failure during `write_active_ref_metadata` was retryable) has
// no strict-`durable_truncate_to_empty`-era equivalent, and is retired the same way and for the same
// reason `wal_directory_component_matrix` was in round 2 -- the asymmetry that kept this one alive a
// round longer (`durable_truncate_to_empty` tolerated a missing directory/file when strict
// `durable_append` already did not) is exactly what §14.8 closed. `default_active_dir()` is
// permanent from `init` (`layout.rs:389`) and nothing removes it, so the fixture's constructed
// state -- directory absent -- is no longer one `write_active_ref_metadata` can recover from, and is
// not reachable from a correctly-`init`ed repository in the first place.
// RFC 102 Stage 4: `ref_log_directory_component_matrix` (proving a first-ref-publish directory
// component failure on `refs/logs/` is retryable) has no container-era equivalent, retired the
// same way and for the same reason `object_directory_component_matrix` was above. The ref-log
// container is allocated once, at `init`, per `layout/tests.rs::init_allocates_every_ref_
// container_name_once` -- a ref publish never creates a directory component at all anymore, so
// this matrix's own `DirectoryCreate`/`CreatedDirectoryParentSync` failpoints are simply never
// reached by `RefStore::publish`, and there is no analogous scenario left to prove here.
// RFC 102 Stage 5, design-v1.md §14.9: `trust_directory_component_matrix` (proving a missing-
// `trust/keys/maintainer/`-directory failure during `add_trusted_maintainer` was retryable) has no
// container-era equivalent, retired the same way and for the same reason `active_metadata_directory_
// component_matrix` was. `maintainer_trust_keys_dir()` doesn't exist as a concept anymore --
// `add_trusted_maintainer` now appends into `trust_dir()` directly, which is permanent from `init`
// (`layout.rs`'s own `required_directories()`) via strict `durable_append`, so there is no nested
// directory left to go missing in the first place.