The channel test only checked that create/send/close returned values, so
it passed while every send failed downstream: channel_send returns a
request id immediately and reports the outcome asynchronously, and with
no listener on onChannelMessageError there was nothing to notice. Asking
the question properly -- two nodes, one channel, does the payload arrive
-- surfaced three things, none of them caused by the nim-ffi migration.
Encryption was never installed, so no segment could ever be sent; that is
fixed in the vendor by naming the mechanism at channel creation.
Autosharding could not be switched on from here at all. A channel's shard
is derived from its content topic, so without it the send cannot even
auto-subscribe. num-shards-in-network exists on the kernel conf but
WakuNodeConfig never exposed it, so it is added here.
Ingress is still dropped below this layer, so channel_message_reaches_peer
is #[ignore]d with the evidence in its doc comment rather than deleted or
weakened into a test that cannot fail. The single-node test keeps its
narrow scope and now says why it asserts nothing about arrival.
The error listeners stay: a send that fails silently is exactly how this
went unnoticed, and they turn a timeout into a diagnosis.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
nim-ffi 0.2.0 generates the Rust bindings from the Nim source, so
bindgen over the hand-written headers is no longer the source of truth
-- and could not be, since those headers describe the pre-CBOR ABI.
The generated sources are referenced in place under vendor rather than
copied, so regenerating them in logos-delivery flows straight through
with nothing to keep in sync. They stay sibling modules because api.rs
resolves its neighbours through `super::`.
build.rs keeps driving the build: it runs the vendor's make target,
scans for the version-and-hash-named nimble package dirs and librln, and
emits the miniupnpc / natpmp / c++ link flags. The generated build.rs
does none of that (it runs a bare `nim c --mm:orc` against a path that
does not resolve here), so only the bindgen half is dropped.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Exposes the reliable-channel surface: channel_create / channel_send /
channel_close on WakuNodeHandle, backed by the logosdelivery_channel_*
FFI calls. Channel state is persisted, so re-creating a closed channel
resumes it rather than starting fresh, and send payloads travel
base64-encoded.
Adds the three channel lifecycle events (received / sent / error) to
WakuEvent, plus the messaging events (sent, error, propagated, received)
and connection status change, so callers can observe delivery rather
than only firing and hoping.
build.rs resolves the nimble package dirs and librln by scanning rather
than hardcoding, since their names carry versions and hashes that move
whenever nimble.lock does. It also checks make's exit status: a failed
build previously passed silently and the crate linked a stale library
from an earlier run.
Bumps the vendor submodule to master.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* build.rs: initialize submodules the first time cargo build is invoked in waku-sys
* messagehash.rs only contains a String as the hex representation of msg hash
* events.rs adapt test to parse message event containing msg-hash in hex string format
* bump nwaku to v0.35.0
* waku-sys/build.rs use STATIC=1 instead of STATIC=true
* bump nwaku to the current master branch ( commit: 625c8ee5 )
* make the waku crate to behave tokio-asynchronously
* use of store
* use of lightpush and filter
* add waku-bindings/src/general/messagehash.rs
* add waku-bindings/src/general/time.rs
* add waku-bindings/src/general/waku_decode.rs
* add WakuEvent management (WakuMessage, ConnectionChange, TopicHealthChange.)
* add waku-bindings/src/macros.rs
* update nwaku vendor to v0.33.1
* build.rs: add negentropy dependency and cmdCount cmdLine dependencies
* fix: call waku_setup when instantiating waku_new
* Properly decode a Vec<Multiaddr>
* First commit tic-tac-toe
* adding some simple game logic to coordinate the turns a little
* some logic to panic if a proper event callback hasn't been set
* restoring back the type state pattern introduced by Richard
* new PubsubTopic type
* fix clippy issues
---------
Co-authored-by: Richard Ramos <info@richardramos.me>
- removes encoding functions from relay and lightpush
- adds `encode_symmetric` and `encode_asymmetric` to `WakuMessage`
- don't panic when unserializing json
* Update vendor
* Expose local archive query
Update to beta4
* Update bindings package to beta4
* Update bindings package to beta4
* Make store response fields public
* Added store configuration
* Use decode response function
* Pipe protocol id
* Fix peer id connect
* Fix WakuPubSubTopic parsing
* Use optional timeout on publish messages
* More test cases
* Update vendor
* Use connect with peer_id
* Fix signal -> event -> message deserialization
* Actively wait for result to arrive the test node
* Clippy happy
* Clippy happy on tests
* Cleaning and adjusting types
* Updated vendor
* Fix keys dance
* Fix lightpush
* Add disconnect test
* Ignore node test for CI
* Add gcc on gh actions
* Reverse installing gcc
* Bring back gcc just for ubuntu and windows
* Removed rust-crypto unused dependency
* Clippy happy
