|
| 1 | +# Mithril Common Architecture Decision Records |
| 2 | + |
| 3 | +--- |
| 4 | + |
| 5 | +## 2. Remove Artifacts serialization support when compiling to WebAssembly |
| 6 | + |
| 7 | +date: 2025-02-26 |
| 8 | +status: Accepted |
| 9 | + |
| 10 | +### Context |
| 11 | + |
| 12 | +After the update to rust `1.85` on `2025-02-21`, we noticed that `mithril-client-wasm` was failing to compile with the error: |
| 13 | + |
| 14 | +``` |
| 15 | +[INFO]: ⬇️ Installing wasm-bindgen... |
| 16 | +thread 'main' panicked at crates/wasm-interpreter/src/lib.rs:245:21: |
| 17 | +mithril_common::signable_builder::interface::_::__ctor::h4977fb9f7c35308c: Read a negative address value from the stack. Did we run out of memory? |
| 18 | +``` |
| 19 | + |
| 20 | +Investigating the problem, we found that the use of `typetag::serde` attribute was causing the issue, as removing them |
| 21 | +allowed the project to compile successfully. |
| 22 | +Furthermore, we found that this is a known issue with `typetag` and WebAssembly, as documented in the `typetag` repository |
| 23 | +[issue #54](https://github.com/dtolnay/typetag/issues/54). |
| 24 | +Why this issue wasn't happening before the update to rust `1.85` is still unknown, as this incompatibility predates the update. |
| 25 | + |
| 26 | +We use the `typetag::serde` attribute to serialize and deserialize Artifacts which are implementing a common trait. |
| 27 | +As of today, this serialization is only used by `mithril-aggregator` to store the Artifacts in the database. |
| 28 | + |
| 29 | +### Decision |
| 30 | + |
| 31 | +We will remove the `typetag::serde` attribute from the Artifacts when compiling to WebAssembly. |
| 32 | + |
| 33 | +### Consequences |
| 34 | + |
| 35 | +Web Assembly will not be able to serialize and deserialize Artifacts using the generic `Artifact` trait. |
| 36 | +This will not affect `mithril-aggregator` as it is not compiled to WebAssembly. |
| 37 | + |
| 38 | +In the future, if we need to serialize and deserialize Artifacts in WebAssembly, we will need to find an alternative solution. |
| 39 | + |
| 40 | +--- |
| 41 | + |
| 42 | +## 1. Record Architecture Decisions |
| 43 | + |
| 44 | +date: 2025-02-26 |
| 45 | +status: Accepted |
| 46 | + |
| 47 | +### Context |
| 48 | + |
| 49 | +We already have a few ADRs in the `docs/website/adr` directory which document project-wide architectural decisions. |
| 50 | +But we also want to document the rationale behind smaller decisions, so they are not lost in the shuffle, avoiding |
| 51 | +the need to rehash the same discussions in the future. |
| 52 | + |
| 53 | +### Decision |
| 54 | + |
| 55 | +We will use Architecture Decision Records, as described by Michael Nygard in this article: http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions |
| 56 | + |
| 57 | +To keep things simple, we will store these ADRs in a single file, and use a simple format to keep them readable. |
| 58 | + |
| 59 | +### Consequences |
| 60 | + |
| 61 | +See Michael Nygard's article, linked above. |
0 commit comments