Repository navigation
Bugfixes - #43
Merged
Merged
Bugfixes#43
Conversation
I overlooked the fact that IPs can be any JavaScript objects, including non-JSONifiable objects. I'm using Underscore for cloning here but let me know which one you prefer. I'm open to any.
bergie
added a commit
that referenced
this pull request
Sep 4, 2012
bergie
added a commit
that referenced
this pull request
Oct 9, 2026
Codecs for the registry handshake, detail exchange, source writes, and library installs: 0x20 sync request, 0x22 manifest (name to sig_hash entries, valid with signature and no source per update #8), 0x23/0x24 detail request/response, 0x25 atomic full-source writes, and 0x27 package install requests. The 0x24 payload carries the declared component kind (elementary, subgraph, stub - never inferred, update #11) and ports as maps with the full #25 field set: id, type, plus optional addressable, description, required, and control; absent optionals are omitted from the wire. Manifest-side names map onto the wire's id convention. sig_hash is SHA-256 over a canonical sorted-key JSON serialization of the kind and port field set, defined here as the cross-repo alignment substrate with noflo-ui #43's canonical serialization (update #10 item 2). SPEC.md pins the payload shapes in the same change set per the AsyncAPI release-gate spirit.
bergie
added a commit
that referenced
this pull request
Oct 12, 2026
From the MicroFlo constrained-runtime port (work document #4 update #43): a client — especially a UI — must be able to programmatically distinguish "you may not do this" from "this runtime cannot do this" from "the frame was malformed". Free-form reason strings cannot. - REASON registry: uint8 codes mirroring the 0x02 limitation codes where semantics overlap (HARDWARE_CONSTRAINED/PERMISSION_DENIED/ LINK_SATURATED/CONCURRENCY_LOCK), plus UNSUPPORTED, UNKNOWN_COMMAND, MALFORMED, PAYLOAD_UNSUPPORTED, STUB, INVALID_STATE, UNKNOWN_TARGET. Additive; no version bump - Non-0x14 rejections answer detail { reason: <code>, message? } — reason required, message optional human text; 0x14 rejections keep the identity triple with free-form reason - Runtime producers mapped: reserved sg/ ids and subgraph-plane drops answer UNSUPPORTED; 0x47 paths answer INVALID_STATE (no running network, injection failure) or UNKNOWN_TARGET (unknown plane, no such exported inport); engine-unsupported commands (pause/step/breakpoints on engines without them) now answer 0x17 UNSUPPORTED to the requester instead of wire silence — the telemetry ERROR event stays for other subscribers - Dropping the main plane (nil plane id) is refused with 0x17 instead of acknowledged (SPEC §5 already said nil is rejected) - SPEC §5 gains the reason registry table; §6's open stub-error item closes: 0x09 STUB on command rejections, 0x09 STUB_ERROR telemetry for engine-raised failures
bergie
added a commit
that referenced
this pull request
Oct 12, 2026
…erpretation rules Work document #4 update #43, from the MicroFlo ESP32-class runtime port. A subset runtime serves a coherent, advertisable subset and declines the rest — it never fails silently. These changes make that normative: - SPEC §1 gains the frame interpretation rules: unrecognized opcodes answer 0x17 UNKNOWN_COMMAND (link never torn down, no speculative decode past the msgpack value boundary); known-but-unhandled commands — including runtime→client opcodes sent by a client — answer 0x17 UNSUPPORTED; undecodable frames answer 0x17 MALFORMED; unknown flowtrace event types are skipped structurally (every event payload is one self-delimiting msgpack value, so skipping is mandatory and cheap); unknown 0x14 op types skip on receive and reject when authoritative - decodeFrame annotates unknown-command errors with REASON.UNKNOWN_COMMAND so receivers can answer precisely; the runtime server's decode site and unhandled-handler site now answer 0x17 instead of staying silent (the unhandledframe/undecodable events stay for host-side visibility) - SPEC §4 gains a SHOULD-registry of well-known runtime_metadata keys — planes ("main" | "ephemeral"), value_model, source — and §3 promotes the announce app_data's frozen three-element shape to normative text (feature advertisement travels in the 0x02 handshake, not the announce) - SPEC §5: a runtime advertising planes:"main" MUST answer 0x16 with only the main plane and MUST answer non-main commands with 0x17 UNSUPPORTED; LIFECYCLE_CTRL with nil plane_id works normally Tests: unknown opcode → 0x17 UNKNOWN_COMMAND with the link surviving; undecodable frame → 0x17 MALFORMED; direction misuse (runtime→client opcode from a client) → 0x17 UNSUPPORTED
bergie
added a commit
that referenced
this pull request
Oct 12, 2026
…erpretation rules Work document #4 update #43, from the MicroFlo ESP32-class runtime port. A subset runtime serves a coherent, advertisable subset and declines the rest — it never fails silently. These changes make that normative: - SPEC §1 gains the frame interpretation rules: unrecognized opcodes answer 0x17 UNKNOWN_COMMAND (link never torn down, no speculative decode past the msgpack value boundary); known-but-unhandled commands — including runtime→client opcodes sent by a client — answer 0x17 UNSUPPORTED; undecodable frames answer 0x17 MALFORMED; unknown flowtrace event types are skipped structurally (every event payload is one self-delimiting msgpack value, so skipping is mandatory and cheap); unknown 0x14 op types skip on receive and reject when authoritative - decodeFrame annotates unknown-command errors with REASON.UNKNOWN_COMMAND so receivers can answer precisely; the runtime server's decode site and unhandled-handler site now answer 0x17 instead of staying silent (the unhandledframe/undecodable events stay for host-side visibility) - SPEC §4 gains a SHOULD-registry of well-known runtime_metadata keys — planes ("main" | "ephemeral"), value_model, source — and §3 promotes the announce app_data's frozen three-element shape to normative text (feature advertisement travels in the 0x02 handshake, not the announce) - SPEC §5: a runtime advertising planes:"main" MUST answer 0x16 with only the main plane and MUST answer non-main commands with 0x17 UNSUPPORTED; LIFECYCLE_CTRL with nil plane_id works normally Tests: unknown opcode → 0x17 UNKNOWN_COMMAND with the link surviving; undecodable frame → 0x17 MALFORMED; direction misuse (runtime→client opcode from a client) → 0x17 UNSUPPORTED
bergie
added a commit
that referenced
this pull request
Oct 12, 2026
Work document #4 update #43 (MicroFlo port): engines declare a value model, and clients must respect it. A packet, IIP, or flowtrace DATA value outside the runtime's declared value model (advertised via the §4 runtime_metadata value_model key) must never crash the runtime or corrupt network state — 0x47 and IIP inserts answer 0x17 PAYLOAD_UNSUPPORTED. Runtime-generated values are in-model by construction, so telemetry needs no gate. The MicroFlo profile (bang, boolean, int, float, buffer, bracket) is recorded as the example. Text-only; the reason code landed with the REASON registry.
bergie
added a commit
that referenced
this pull request
Oct 12, 2026
Work document #4 update #43 (MicroFlo port): a mesh-isolated microcontroller has no RTC and no NTP, so timestamp fields cannot be assumed UTC-aligned. SPEC §7 records that timestamp provenance is runtime policy — monotonic-derived counters (for example a hybrid logical clock) are conforming — and that consumers MUST NOT assume cross-runtime UTC alignment: timestamps are comparable only per runtime. 0x48 uptime_ms is monotonic by definition. Text-only.
bergie
added a commit
that referenced
this pull request
Oct 12, 2026
Work document #4 update #43 (MicroFlo port): a mesh-isolated microcontroller has no RTC and no NTP, so timestamp fields cannot be assumed UTC-aligned. SPEC §7 records that timestamp provenance is runtime policy — monotonic-derived counters (for example a hybrid logical clock) are conforming — and that consumers MUST NOT assume cross-runtime UTC alignment: timestamps are comparable only per runtime. 0x48 uptime_ms is monotonic by definition. Text-only.
bergie
added a commit
that referenced
this pull request
Oct 12, 2026
The unknown-command annotation in decode.js (update #43) attached a .reason property to ProtocolError instances without declaring it — CI's type check caught what my local run missed (I re-ran tests but skipped tsc for fbp-protocol on that commit). The reason code is now a proper third constructor parameter on the class; the gitignored errors.d.ts regenerates from it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@bergie I know you're in Istanbul this week. Here's some minor bug fixes that should take just a few minutes to review when you get back. :)
For the 'RemoveProperties' component, when you split an IP before removing a property and intend to use the original value in different ways, the current implementation wouldn't allow that, hence the patch.
This is actually a more general problem. Do you think having a 'Copy' component is better than selectively copying for some special components like this one?
Note that I would normally use
owl.deepCopy()and the like to copy the object. I try to be lib-less but if you have a preferred deep copying library, I'd use that.