feat: updated logic to now consider mentions while filtering

[NiravJoshi33]

Fixes Issue #242

Implements the missing mentions field filtering in the logsSubscribe/logsUnsubscribe WebSocket functionality.

• I have implemented filter logic in notify_logs_subscribers method
• It now supports All, AllWithVotes, and Mentions(Vec<String>) filters
• Early continue when commitment level doesn't match

Next Steps: Tests covering different behaviors of this feature.

Feedback is very much welcomed. Happy to iterate on the approach before investing time in tests.

[NiravJoshi33]

Hi,

I am excited to contribute to Surfpool. This is my first Rust PR, so I have focused on getting the core logic right before writing tests.

I'd especially appreciate feedback on:

• My understanding of the transaction structure
• Rust idioms and performance considerations
• Any preferred testing patterns for WebSocket subscription features

I am ready to quickly iterate based on your feedback.

[MicaiahReid]

This is awesome, @NiravJoshi33! The logic looks great, with some clean rust patterns! Well done!

I'm realizing we don't actually have tests for WS RPC methods yet. Would you want to tackle the first ones?

Our integration.rs file has examples of setting up tests and invoking regular RPC methods. At the bottom of the file I've pushed the test test_ws_scaffold, which should do the basic set up of the test for you!

[MicaiahReid]

Ah, actually I couldn't push to your fork! You can enable me pushing, or this is the fn I added to the bottom of integration.rs

#[tokio::test(flavor = "multi_thread")]
async fn test_ws_scaffold() {
    use std::sync::RwLock as StdRwLock;
    let (svm_instance, _simnet_events_rx, _geyser_events_rx) = SurfnetSvm::new();

    let svm_locker = SurfnetSvmLocker::new(svm_instance);

    let runtime = tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .build()
        .expect("Failed to build Tokio runtime");

    let tokio_handle = runtime.handle();

    let uid = std::sync::atomic::AtomicUsize::new(0);
    let ws_server = crate::rpc::ws::SurfpoolWsRpc {
        uid,
        signature_subscription_map: Arc::new(StdRwLock::new(HashMap::new())),
        account_subscription_map: Arc::new(StdRwLock::new(HashMap::new())),
        slot_subscription_map: Arc::new(StdRwLock::new(HashMap::new())),
        logs_subscription_map: Arc::new(StdRwLock::new(HashMap::new())),
        tokio_handle: tokio_handle.clone(),
    };

    // subscribe to a method you want to test
    // use the svm_locker to write to the vm and/or trigger events
}

[NiravJoshi33]

Thanks so much @MicaiahReid! Really appreciate the feedback and the test scaffold. 🙏

I'll check the test scaffold and study existing patterns, and start working on the tests.

Thanks for the opportunity to work on something foundational.

[MicaiahReid]

Hey @NiravJoshi33, any updates on those tests?

[NiravJoshi33]

Hi @MicaiahReid, I am working on them but got little busy with something else. I'll make some more progress with them and share it in this pr for your review within 1-2 days.

[NiravJoshi33]

I have added comprehensive tests for the ws methods:

Total 22 tests for the implemented 4 methods.

• Signature Subscription (6 tests): different commitment levels, failed transactions, multiple subscribers
• Account Subscription (5 tests): balance changes, account creation/closure, concurrent subscription
• Slot Subscription (4 tests): manual and automatic slot advancement, multiple subscribers, sequential updates
• Logs Subscription (7 tests): all/mentions fiters, different commitment levels, failed transactions, log content validation

These tests validate the internal subscription mechanisms rather than full E2E websocket connections. This approach is consistent with existing integration tests and provides comprehensive coverage of the subscription notification logic.

[MicaiahReid]

@NiravJoshi33, this is incredible! Thank you for adding all of these tests!

I added some minor changes, but I'm good to approve. My changes were:

• use the test_case import to simplify some repeat logic on the signature subscription tests
• for the logs subscriptions, I added a mentions filter that should not be yielding log results to assert that the mentions will properly filter logs out (your test confirmed that mentioned accounts would be in the logs, but not the other way around as well)
• cleaned up imports