Tx evaluation by ginnun · Pull Request #378 · blockfrost/blockfrost-platform

ginnun · 2025-09-12T10:03:16Z

Resolves #306

Context

The goal of this PR is to implement tx evaluation APIs while trying to stay compatible to the Blockfrost.io version, which are:

/utils/txs/evaluate
/utils/txs/evaluate/utxos

What is added

Two new endpoints and tests under a new compile configuration: evaluate
New cardano node client functions related to ledger: protocol_params and genesis_config
pallas_validate handling
Native tx evaluation in Rust using pallas (incomplete)
External tx evaluation in Haskell using ledger via a compiled binary

What is changed

Test folder layout. Now we can have separate files for each endpoint tests. This makes sense since we are going to have lots of them.
Underlying commit of the pallas tag. I ended up fixing a non-working part in pallas. So changed the hash of the tag. (I want to use tagging better in the future)
cargo.lock file content

Considerations

I am getting the protocol params and genesis from the Cardano node every time. This can be changed to use the new static implementation (or cached)
The build configuration evaluate will be built by default except windows and linux-aarch64 platforms (handled in build.rs).
The build configuration evaluate enables tx evaluation endpoints. It exists since pallat-validate crate isn't building for windows-all and linux-aarch64 at the moment.

Please run cargo clean to make sure everything is in a fresh state before compiling.

Related PRs

Haskell part: Implemented eval tx stream testgen-hs#3
Pallas: Lots of fixes and updated to the latest node version txpipe/pallas#624

cloudflare-workers-and-pages · 2025-09-12T10:54:52Z

Deploying blockfrost-platform with Cloudflare Pages

Latest commit:	`704ddab`
Status:	✅ Deploy successful!
Preview URL:	https://3e28e244.blockfrost-platform.pages.dev
Branch Preview URL:	https://feat-tx-evaluation-rebased.blockfrost-platform.pages.dev

View logs

michalrus

Hey, I started reviewing, but then noticed that it's a draft! Left a few comments either way :)

nix/internal/unix.nix

src/api/utils/txs/evaluate/model.rs

crates/testgen/src/testgen.rs

crates/node/src/cbor/fallback_decoder.rs

…ra tx-gen features)

michalrus · 2026-01-20T15:33:53Z

Maybe let's have a simpler merge commit for the current conflicts? 🥺 Unless you're using git-rerere.

…based

michalrus

One quick comment about the other repo (Pallas), and now I'll process the rest (here):

michalrus · 2026-03-23T16:21:35Z

Cargo.toml

+pallas-addresses = { git = "https://github.com/blockfrost/pallas.git", tag = "blockfrost-platform-0.0.3-alpha6" }
+pallas-codec = { git = "https://github.com/blockfrost/pallas.git", tag = "blockfrost-platform-0.0.3-alpha6" }
+pallas-crypto = { git = "https://github.com/blockfrost/pallas.git", tag = "blockfrost-platform-0.0.3-alpha6" }
+pallas-hardano = { git = "https://github.com/blockfrost/pallas.git", tag = "blockfrost-platform-0.0.3-alpha6" }


BTW, this tag resolves to:

txpipe/pallas@e8681d3

Which is a part of:

Lots of fixes and updated to the latest node version txpipe/pallas#624

I have linked this PR in description of this PR.

⚠️ But I see that in this Pallas PR there are a lot of issues detected by their AI, and they haven’t merged it yet. From a quick look, a few unwraps on calculations done on user-supplied data, so similar issues that were tackled in this PR.

Could you fix these issues there, so that they accept? And I'll review that one, too. Because otherwise, we still have unwraps in our code, just hidden under these dependency changes that the upstream didn’t approve.

Thanks for flagging this. I have an open tab for the fixes and I am already working on it.

Background:
I opened that PR long before the AI reviews came in (major part of the PR), it was waiting for a merge for a while. So I doubt that that PR will get merged even after I satisfy the CodeRabbit.

CodeRabbit findings are valid. But the AI flagged topics are already present throughout the existing codebase. My code followed the existing conventions, but I'm happy to raise the bar on the new code I'm adding. Meanwhile, this should not be a blocker on this PR.

Hmmm, but what do you think about this comment txpipe/pallas#624 (comment)? I'm not sure if we should have unwraps in production code, but I haven’t reviewed that Pallas PR myself yet, just looked at their AI review.

I mean we got rid of unwraps here, so why not there? It's also the code we're running just in a different repository.

Even though we wrote it, these are in a completely different repository. I am not saying we should not fix problems there, I am saying it should not be a blocker to merge this PR. Because now we've started reviewing another PR right now.

And they (Pallas) haven’t done it for us, because that PR is not merged yet

(So I'll just make that proper review there, too, maybe their bot is lying 🤞 )

By the way, the bot's points are valid. I am fixing them.

@michalrus txpipe/pallas#624 is ready.

Okay – I've just submitted my review there, a couple of comments:

Lots of fixes and updated to the latest node version txpipe/pallas#624 (review)

michalrus

Okay – another round done! The most important comment is about blockfrost-tests, I think.

michalrus · 2026-03-23T19:38:41Z

crates/gateway/Cargo.toml

 [dev-dependencies]
+reqwest.workspace = true
 rstest.workspace = true
+tokio-tungstenite.workspace = true


Surprising – why would this PR need to change this? Hmmm. If it's failing checks, then why is the main check passing? 🤔

Yeah, I didn't notice this difference between CI and my PR. Tho:

> nix develop --command cargo shear warning: Git tree '/home/sefa/dev/blockfrost-platform' is dirty shear/misplaced_dependency × misplaced dependency `reqwest` ╭─[crates/gateway/Cargo.toml:25:1] 24 │ chrono = { workspace = true, features = ["serde"] } 25 │ reqwest.workspace = true · ───┬─── · ╰── only used in dev targets 26 │ blockfrost.workspace = true ╰──── help: move this dependency to `[dev-dependencies]` shear/misplaced_dependency × misplaced dependency `tokio-tungstenite` ╭─[crates/gateway/Cargo.toml:14:1] 13 │ futures-util.workspace = true 14 │ tokio-tungstenite.workspace = true · ────────┬──────── · ╰── only used in dev targets 15 │ tungstenite.workspace = true ╰──── help: move this dependency to `[dev-dependencies]`

michalrus · 2026-03-23T19:45:44Z

crates/platform/src/api/utils/txs/evaluate/utxos.rs

+            if version != 6 {
+                Err(BlockfrostError::conflicting_ogmios_version())
+            } else {
+                let tx_cbor = binary_or_hex_heuristic(request.transaction.cbor.as_bytes());


Hmmm, I wonder, won’t this always be hex-encoded? tx_request, and therefore the request variant will always be some kind of JSON. You think someone would pass:

{ "cbor": "\u0001\u0002\u0003" }

etc.? Is this format used?

The same question for other instances below.

@michalrus Yes true, not Ogmios related. Removed in 69f459d.

michalrus · 2026-03-23T19:49:35Z

crates/platform/tests/api/utils/txs/evaluate/utxos.rs

+    };
+    use reqwest::Method;
+
+    ///


How does this look in cargo doc? Do they treat first non-empty comment line as the first comment line? Or is the first line empty? Is it a doc comment /// or a regular one, //?

This will produce an empty line. Removed in f71720d.

michalrus · 2026-03-23T19:55:57Z

crates/integration_tests/tests/data/supported_endpoints.json

@@ -37,5 +37,7 @@
  "/epochs/latest/parameters",
  "/genesis",
  "/addresses/{address}/transactions",
-  "/addresses/{address}/utxos"
+  "/addresses/{address}/utxos",
+  "/utils/txs/evaluate",


A-ha! 🔍

You can see that blockfrost-tests are failing now:

FAIL src/tests/mainnet/routes.ts > Integration Tests - mainnet > utils endpoints > [utils/txs/evaluate/utxos with additional utxo set (JSON)] - utils/txs/evaluate/utxos

(Please, also look at the Preview and Preprod runs.)

In general we need to merge the current main, because on your old main, the GitHub workflow was marked to always pass. Please see this PR by @vladimirvolek for more context:

fix(tests): get rid of continue-on-error: true #473

BTW, you can reproduce this locally by running:

nix run -L .#internal.x86_64-linux.blockfrost-tests-preview

It will ask you for a few env. variables, like Dolos URL or node socket path, or a funded tADA wallet etc., but once you provide them, it will work the same as on CI.

And you can easily run a decent Dolos with run-dolos-preview inside the devshell.

But since you don’t need to test any Dolos integration, you can just as well comment it out!

Sadly, the first approach was the correct one in this PR. I returned back to the original approach with improvements. I've added extensive commenting, but summary here:

We use HashMaps for both sides (Rust & Haskell):

node_utxo_map: on-chain UTxOs keyed by (tx_hash, index)

additional_deduped: user-provided UTxOs, also keyed the same way

Conflicts (same TxIn, different TxOut) are rejected with a 400 error before merging. Identical duplicates are silently dropped. Only non-overlapping additional UTxOs survive. User provided data is least important, loses against the node provided data always in conflict.

I should underline, we don't have mempool integration yet (Ogmois does use mempool + chain)

On the Haskell side: the external evaluator receives CBOR-encoded UTxOs which it deserializes into a Map (specifically Data.Map.fromList), so even if there were duplicates in the vector, last entry would win. But we ensure there are none.

in ac3a652.

michalrus · 2026-03-23T19:59:35Z

crates/testgen/src/testgen.rs

@@ -0,0 +1,310 @@
+use bf_common::errors::AppError;


Hmmm, I'm thinking perhaps we should make a small PR on main, unrelated to this one, where we move the testgen.rs code to this new mini crate. This way we'll be able to better catch conflicts if something changes there. Now it's easy for the two implementations to diverge, and during conflict resolution just "accept ours" since we deleted the original file in this PR. Just a thought.

I will check how they actually differ before the merge of this one!

Do you mean, eagerly doing this crate's refactoring in the main? If so I can do that.

michalrus · 2026-03-23T20:15:36Z

crates/tx_evaluator/src/model/api.rs

+    }
+}
+
+impl<'de> Deserialize<'de> for DeserializationErrorData {


Hmmmm, you're deriving Serialize above:

blockfrost-platform/crates/tx_evaluator/src/model/api.rs

Lines 184 to 185 in fe4dd66

#[derive(Serialize, Debug)]

pub struct DeserializationErrorData {

… so after this generic serialization, it ends up as JSON object with 6 fields.

But here, it seems like you're deserializing a single string?

So serializer is not a inversion of deserializer, and they don’t match? I think in general JSON codecs should be invertible, or it’s surprising.

You're right that Serialize and Deserialize are not invertible here. The custom Deserialize impl accepts a single string (from our internal deserialization error path) and expands it into all 6 era fields via conway_only(), while Serialize (derived) outputs the full 6-field JSON object matching the Ogmios response format. This asymmetry is intentional: Ogmios returns all 6 era fields with era-specific error messages, so we replicate that structure for API consumers. But since we only decode in Conway era, on the deserialization side we just take a single string and copy it across all eras.

Added a doc comment in db94c15.

michalrus · 2026-03-23T20:19:33Z

crates/tx_evaluator/src/native.rs

+
+        utxos.insert(TxoRef::from(&multi_era_in), EraCbor::from(multi_era_out));
+    }
+    let mut node = node_pool.get().await?;


Hmmm. No, no, wait, you're acquiring a second node connection from the pool here. There first one is acquired here:

blockfrost-platform/crates/tx_evaluator/src/native.rs

Line 78 in fe4dd66

let mut node = node_pool.get().await?;

And in that function you later call this one, which acquires the second one:

blockfrost-platform/crates/tx_evaluator/src/native.rs

Line 90 in fe4dd66

evaluate_tx_with_pp(

It can lead to exhaustion, let's have a single node connection for one request.

Let's move this conversation into to sub-PR: https://github.com/blockfrost/blockfrost-platform/pull/490/files#r2980627802
It's commented as a to-do there:

// TODO: This evaluator fetches genesis_config_and_pp() from the node on every
// request. It should use ChainConfigWatch to read cached chain config instead.
// Deferred because this native evaluator is currently unused (pallas-validate
// results differ from the Haskell ledger / Ogmios).

michalrus · 2026-03-23T20:22:51Z

crates/tx_evaluator/src/native.rs

+        convert_bigint(&sys_start.year)? as i32,
+        sys_start.day_of_year as u32,
+    )
+    .expect("Invalid system start date");


Hmmm, this is called in convert_protocol_param, which is called in evaluate_tx, so for each request. Is this expect here okay? It’s not only on launch, but potentially for every request.

michalrus · 2026-03-23T20:29:41Z

crates/tx_evaluator/src/native.rs

+    let conway_pp: ConwayProtParams = ConwayProtParams {
+        minfee_a: pp.minfee_a.unwrap() as u32,
+        minfee_b: pp.minfee_b.unwrap() as u32,
+        max_block_body_size: pp.max_block_body_size.unwrap() as u32,


There's a lot of panicking unwrap()s here on potentially None values.

And yet the returned type is Result<_,_>.

Can you say more?

michalrus · 2026-03-23T20:31:29Z

crates/tx_evaluator/src/ogmios5_response.rs

+                script_failures,
+                key,
+                "noCostModelForLanguage",
+                json!(missing_models[0]),


I'm almost sure I asked about this already, but have forgotten the answer. Why is it only the first one?

In this case, if this is absolutely correct, can you add an XXX: comment near it? So that it’s always obvious in the future.

Added comment in 0edc8b6.

…Data

ginnun

@michalrus I replied, but kept them in pending for a while ^^

ginnun · 2026-03-24T10:45:53Z

crates/tx_evaluator/src/native.rs

+
+        utxos.insert(TxoRef::from(&multi_era_in), EraCbor::from(multi_era_out));
+    }
+    let mut node = node_pool.get().await?;


Let's move this conversation into to sub-PR: https://github.com/blockfrost/blockfrost-platform/pull/490/files#r2980627802
It's commented as a to-do there:

// TODO: This evaluator fetches genesis_config_and_pp() from the node on every
// request. It should use ChainConfigWatch to read cached chain config instead.
// Deferred because this native evaluator is currently unused (pallas-validate
// results differ from the Haskell ledger / Ogmios).

ginnun · 2026-03-24T11:50:04Z

crates/tx_evaluator/src/ogmios5_response.rs

+                script_failures,
+                key,
+                "noCostModelForLanguage",
+                json!(missing_models[0]),


Added comment in 0edc8b6.

ginnun · 2026-03-24T11:55:05Z

crates/testgen/src/testgen.rs

@@ -0,0 +1,310 @@
+use bf_common::errors::AppError;


Do you mean, eagerly doing this crate's refactoring in the main? If so I can do that.

ginnun · 2026-03-24T11:57:57Z

crates/tx_evaluator/src/model/api.rs

+
+/// If language is native, the json structure can be one of cbor or json
+/// If language is plutus, only cbor field is expected
+///  "script": {


👍 in adb945d

ginnun · 2026-03-24T12:13:07Z

crates/gateway/Cargo.toml

 [dev-dependencies]
+reqwest.workspace = true
 rstest.workspace = true
+tokio-tungstenite.workspace = true


Yeah, I didn't notice this difference between CI and my PR. Tho:

> nix develop --command cargo shear warning: Git tree '/home/sefa/dev/blockfrost-platform' is dirty shear/misplaced_dependency × misplaced dependency `reqwest` ╭─[crates/gateway/Cargo.toml:25:1] 24 │ chrono = { workspace = true, features = ["serde"] } 25 │ reqwest.workspace = true · ───┬─── · ╰── only used in dev targets 26 │ blockfrost.workspace = true ╰──── help: move this dependency to `[dev-dependencies]` shear/misplaced_dependency × misplaced dependency `tokio-tungstenite` ╭─[crates/gateway/Cargo.toml:14:1] 13 │ futures-util.workspace = true 14 │ tokio-tungstenite.workspace = true · ────────┬──────── · ╰── only used in dev targets 15 │ tungstenite.workspace = true ╰──── help: move this dependency to `[dev-dependencies]`

ginnun · 2026-03-24T12:23:39Z

crates/platform/tests/api/utils/txs/evaluate/utxos.rs

+    };
+    use reqwest::Method;
+
+    ///


This will produce an empty line. Removed in f71720d.

ginnun · 2026-03-24T12:52:51Z

crates/tx_evaluator/src/model/api.rs

+    }
+}
+
+impl<'de> Deserialize<'de> for DeserializationErrorData {


You're right that Serialize and Deserialize are not invertible here. The custom Deserialize impl accepts a single string (from our internal deserialization error path) and expands it into all 6 era fields via conway_only(), while Serialize (derived) outputs the full 6-field JSON object matching the Ogmios response format. This asymmetry is intentional: Ogmios returns all 6 era fields with era-specific error messages, so we replicate that structure for API consumers. But since we only decode in Conway era, on the deserialization side we just take a single string and copy it across all eras.

Added a doc comment in db94c15.

ginnun · 2026-03-24T13:24:10Z

crates/platform/src/api/utils/txs/evaluate/utxos.rs

+            if version != 6 {
+                Err(BlockfrostError::conflicting_ogmios_version())
+            } else {
+                let tx_cbor = binary_or_hex_heuristic(request.transaction.cbor.as_bytes());


@michalrus Yes true, not Ogmios related. Removed in 69f459d.

ginnun · 2026-03-24T13:57:31Z

Cargo.toml

+pallas-addresses = { git = "https://github.com/blockfrost/pallas.git", tag = "blockfrost-platform-0.0.3-alpha6" }
+pallas-codec = { git = "https://github.com/blockfrost/pallas.git", tag = "blockfrost-platform-0.0.3-alpha6" }
+pallas-crypto = { git = "https://github.com/blockfrost/pallas.git", tag = "blockfrost-platform-0.0.3-alpha6" }
+pallas-hardano = { git = "https://github.com/blockfrost/pallas.git", tag = "blockfrost-platform-0.0.3-alpha6" }


@michalrus txpipe/pallas#624 is ready.

ginnun · 2026-03-26T15:31:45Z

crates/integration_tests/tests/data/supported_endpoints.json

@@ -37,5 +37,7 @@
  "/epochs/latest/parameters",
  "/genesis",
  "/addresses/{address}/transactions",
-  "/addresses/{address}/utxos"
+  "/addresses/{address}/utxos",
+  "/utils/txs/evaluate",


Sadly, the first approach was the correct one in this PR. I returned back to the original approach with improvements. I've added extensive commenting, but summary here:

We use HashMaps for both sides (Rust & Haskell):

node_utxo_map: on-chain UTxOs keyed by (tx_hash, index)

additional_deduped: user-provided UTxOs, also keyed the same way

Conflicts (same TxIn, different TxOut) are rejected with a 400 error before merging. Identical duplicates are silently dropped. Only non-overlapping additional UTxOs survive. User provided data is least important, loses against the node provided data always in conflict.

I should underline, we don't have mempool integration yet (Ogmois does use mempool + chain)

On the Haskell side: the external evaluator receives CBOR-encoded UTxOs which it deserializes into a Map (specifically Data.Map.fromList), so even if there were duplicates in the vector, last entry would win. But we ensure there are none.

in ac3a652.

For example: The API documentation example incorrectly uses "cpu" without "EvaluationResult" wrapper, but the actual Ogmios v5.6 JSON schema (ogmios.wsp.json) and source code use "steps" with "EvaluationResult".

…lockfrost API

ginnun · 2026-04-02T10:04:24Z

crates/common/src/helpers.rs


    if !even_length || contains_non_hex {
-        xs.to_vec()
+        use base64::{Engine as _, engine::general_purpose};


@michalrus Please see if this change doesn't belong here (I can separate). This is needed since hosted Blockfrost API accepts base64 in evaluate endpoint.

…ting

ginnun marked this pull request as draft September 12, 2025 10:03

michalrus reviewed Sep 16, 2025

View reviewed changes

michalrus mentioned this pull request Sep 16, 2025

Implement tx submit evaluation via pallas & haskell #322

Closed

ginnun force-pushed the feat/tx-evaluation-rebased branch 3 times, most recently from c702f03 to a53a53c Compare September 22, 2025 12:06

ginnun changed the title ~~Feat/tx evaluation rebased~~ Tx evaluation Sep 23, 2025

ginnun force-pushed the feat/tx-evaluation-rebased branch 2 times, most recently from 3bcc5c5 to e67b1a9 Compare October 10, 2025 11:35

michalrus linked an issue Nov 17, 2025 that may be closed by this pull request

Add POST /utils/txs/evaluate – how many execution units for a transaction #306

Open

ginnun marked this pull request as ready for review December 15, 2025 10:02

ginnun and others added 16 commits January 15, 2026 15:44

Implement tx submit evaluation via pallas

a22596f

Ignare dead code warnings in the test code

dc47186

Update pallas and resolve breaking changes

6a2936c

chore: add missing compile-time dependencies

c89861b

chore: relax cargo-deny

c690b6a

chore: fix the OCI (Docker) build

29c311f

feat: Create compile config 'evaluate'

da35ae6

fix: aarch64-linux compilation of Pallas’ phase2

39770c1

fix: a silly redirection bug

dbc5a7b

fix: devshell on aarch64-linux

0aa3dc3

fix: don’t use musl on aarch64-linux – back to GNU

603cf52

fix: drop -fexternal-interpreter for plutus-core

a318c4c

chore: update nixpkgs for the new Rust and Clippy

f1f90e6

chore: apply Clippy’s corrections

64376fb

chore: use the native aarch64-linux build of testgen-hs (with ext…

92d3225

…ra tx-gen features)

feat: Native Rust evaluate, Haskell evaluate and tests

f269525

ginnun force-pushed the feat/tx-evaluation-rebased branch from 6980be7 to f269525 Compare January 16, 2026 09:32

ginnun added 10 commits March 13, 2026 14:41

fix: remove orphan test files never included in compilation

342e067

Merge branch 'main' into feat/tx-evaluation-rebased

f82990b

Merge remote-tracking branch 'origin/main' into feat/tx-evaluation-re…

0e7ebc7

…based

fix: inherit workspace version/license/edition in error_decoder

0115157

Merge remote-tracking branch 'origin/main' into feat/tx-evaluation-re…

ef3bbb5

…based

fix: remove unused deps

434da48

fix: skip ExternalDecoder cross-validation under tarpaulin

f82af34

fix: gate ExternalDecoder and assert_json_eq behind tarpaulin cfg

164b526

fix: remove unused deps -2-

eb29909

fix: remove unused workspace deps (bf-error-decoder, pallas, serde_with)

fe4dd66

ginnun self-assigned this Mar 18, 2026

ginnun added the enhancement New feature or request label Mar 18, 2026

michalrus requested changes Mar 23, 2026

View reviewed changes

ginnun mentioned this pull request Mar 24, 2026

feat: lazy chain config init via ChainConfigWatch with epoch-boundary… #490

Open

ginnun added 5 commits March 24, 2026 14:49

fix: Add comment for noCostModelForLanguage

0edc8b6

docs: fix JSON doc comment formatting in ScriptV6

adb945d

docs: remove empty doc comment lines in utxos test

f71720d

docs: clarify Serialize/Deserialize asymmetry in DeserializationError…

db94c15

…Data

refactor: replace binary_or_hex_heuristic wit hex::decode

69f459d

ginnun commented Mar 26, 2026

View reviewed changes

ginnun added 7 commits March 26, 2026 18:34

fix: user provided utxo merging

ac3a652

Merge branch 'main' into feat/tx-evaluation-rebased

39237ce

fix: remove unused dev-dependencies flagged by cargo-machete

22d0873

fix(tx-evaluator): align v5 response format with Ogmios v5.6 JSON schema

db5fc29

For example: The API documentation example incorrectly uses "cpu" without "EvaluationResult" wrapper, but the actual Ogmios v5.6 JSON schema (ogmios.wsp.json) and source code use "steps" with "EvaluationResult".

fix(tx-evaluator): align v5/v6 response format with Ogmios spec and B…

f25b7a8

…lockfrost API

fix(tx-evaluator): Formatting

279472c

feat: add base64 decode support to binary_or_hex_heuristic

61c13a1

ginnun commented Apr 2, 2026

View reviewed changes

fix(tx-evaluator): align v5 error parsing with testgen-hs message nes…

704ddab

…ting

	#[derive(Serialize, Debug)]
	pub struct DeserializationErrorData {

Conversation

ginnun commented Sep 12, 2025 • edited by michalrus Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Context

Related PRs

Uh oh!

cloudflare-workers-and-pages bot commented Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying blockfrost-platform with Cloudflare Pages

Uh oh!

michalrus left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

michalrus commented Jan 20, 2026

Uh oh!

michalrus left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ginnun Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

michalrus Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

michalrus Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

michalrus Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

michalrus left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ginnun Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ginnun commented Sep 12, 2025 •

edited by michalrus

Loading

cloudflare-workers-and-pages bot commented Sep 12, 2025 •

edited

Loading

ginnun Mar 23, 2026 •

edited

Loading

michalrus Mar 23, 2026 •

edited

Loading

michalrus Mar 23, 2026 •

edited

Loading

michalrus Mar 24, 2026 •

edited

Loading

ginnun Mar 26, 2026 •

edited

Loading

ginnun left a comment •

edited

Loading