invalid activity result type: 110

[typedrat]

nix-output-monitor error: ParseNixJSONMessageError "InternalException (DocumentError {path = \"\", errorMsg = \"invalid activity result type: 110\"})" "{\"action\":\"result\",\"id\":282643207821159,\"payload\":{\"builtOutputs\":{\"out\":{\"path\":\"vn3n7i6xjihc5nvy83djxz9pixbrc7j2-fontconfig-conf\",\"signatures\":[]}},\"path\":{\"drvPath\":\"fckamp4g15c88ai45w46pi1fjyp0yifl-fontconfig-conf.drv\",\"outputs\":[\"*\"]},\"startTime\":1755289374,\"status\":\"Built\",\"stopTime\":1755289375,\"timesBuilt\":1},\"type\":110}"

[maralorn]

Hey, there @typedrat. Thank you for your bug report. Sadly I am lacking context to reproduce this error. (With the added nuisance that buy a copy&paste error this error message appears twice in the nom source although it should only occure once.)

I checked the nix and the lix source and couldn’t find any changes regarding activity result types.

Could you provide any information which could help me locate the issue? e.g. which nix and nom version are you using? Which command where you running? Ideally explicit steps for reproducing this.

[maralorn]

On further investigation. This looks really different from what our parser expects. Are you on some experimental branch of something?

[maralorn]

I have at least fixed the ambiguous error message in #194

[typedrat]

Oh, doy! Yeah, I meant to give more information and just posted this hoping it'd be a reminder to myself... looks like that didn't work. 😛

❯ nom --version
nix-output-monitor 2.1.6
nix (Determinate Nix 3.8.5) 2.30.2

This happens any time that Nix downloads from a binary cache. It's specifically triggering via a nixos-rebuild build in the example I gave above, but I can get a similar message nix runing something that's not already in my local store.

Here's the specific line that defines the message type: libutil/include/nix/util/logging.hh#43

The payload is specifically a serialized KeyedBuildResult, but that's as far as I was able to unwind things without actually knowing much about how Nix works internally.

It looks like they're getting generated at these three locations:

1. libstore/build/substitution-goal.cc
2. libstore/build/derivation-building-goal.cc
3. libstore/build/derivation-goal.cc

[maralorn]

Oh, wow. Thank you. I didn’t know that determinate nix is diverging here from upstream.