Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TopicClient always receive 401 #1637

Closed
Gaelik-git opened this issue Apr 12, 2024 · 2 comments · Fixed by #1638
Closed

TopicClient always receive 401 #1637

Gaelik-git opened this issue Apr 12, 2024 · 2 comments · Fixed by #1638
Labels
bug This issue requires a change to an existing behavior in the product in order to be resolved. Client This issue points to a problem in the data-plane of the library. Service Bus Service Bus

Comments

@Gaelik-git
Copy link
Contributor

I created a Service Bus Namespace with:

  • One Queue : dev
  • One Topic : test-topic
    • One Subscription : test-subscription

I also have a Sharred access Policies on the Namespace level named common
But the topic client always receives a 401, when my QueueClient receives 204

Can you help me with this ? Is my code incorrect ?
Can it be linked to the ordering when creating things ?
I am using the latest 0.19 version of the sdk with rust 1.77.1

This is the result of this test program

INFO peeked message queue val=204
INFO send message to topic ko=Error { context: Simple(HttpResponse { status: Unauthorized, error_code: None }) }
INFO peeked message from subscription val=401
use azure_messaging_servicebus::service_bus::{QueueClient, TopicClient};
use reqwest::Client;
use std::sync::Arc;
use std::time::Duration;
use tracing::{info, subscriber::set_global_default};

#[tokio::main]
async fn main() {
    // common conf
    let namespace = "REDACTED";
    let policy_name = "common";
    let policy_key = "REDACTED";

    // topic conf
    let topic_name = "test-topic";
    let subscription_name = "test-subscription";

    // queue conf
    let queue_name = "dev";

    set_global_default(tracing_subscriber::fmt::Subscriber::new())
        .expect("set tracing default subscriber");

    let client = QueueClient::new(
        Arc::new(Client::new()),
        namespace,
        queue_name,
        policy_name,
        policy_key,
    )
    .unwrap();
    let val = client
        .peek_lock_message2(Some(Duration::from_micros(1)))
        .await
        .unwrap();

    info!(val = %val.status(), "peeked message queue");
    let client = TopicClient::new(
        Arc::new(Client::new()),
        namespace,
        topic_name,
        policy_name,
        policy_key,
    )
    .unwrap();

    let val = client.topic_sender().send_message("msg").await;

    match val {
        Ok(_) => info!(ok = ?val.is_ok(), "send message to topic"),
        Err(_) => info!(ko = ?val.unwrap_err(), "send message to topic"),
    }

    let val = client
        .subscription_receiver(subscription_name)
        .peek_lock_message2(Some(Duration::from_micros(1)))
        .await
        .unwrap();

    info!(val = %val.status(), "peeked message from subscription");
}
@Gaelik-git
Copy link
Contributor Author

Gaelik-git commented Apr 12, 2024

I think it might a bug introduced in v0.18

When using the v0.17 of this crate I get better result, I am able to send message to the topic but reading from the subscription is still ko

2024-04-12T16:31:31.347529Z  INFO: peeked message queue val=204
2024-04-12T16:31:31.597199Z  INFO: send message to topic ok=true
2024-04-12T16:31:32.730468Z  INFO: peeked message from subscription val=405

This is the body of the 405 reponse

<Error>
   <Code>405</Code>
   <Detail>It is not possible for an entity that requires sessions to create a non-sessionful message receiver. TrackingId:0d889d68-0ab2-4a03-b080-9dbae72678b1_G19_B22, SystemTracker:REDACTED:Topic:test-topic|test-subscription, Timestamp:2024-04-12T17:11:24</Detail>
</Error>

@Gaelik-git
Copy link
Contributor Author

Looks like the fix on this commit should also be on the TopiClient c999ef3

@RickWinter RickWinter added bug This issue requires a change to an existing behavior in the product in order to be resolved. Client This issue points to a problem in the data-plane of the library. Service Bus Service Bus labels Apr 15, 2024
@RickWinter RickWinter linked a pull request Apr 15, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue requires a change to an existing behavior in the product in order to be resolved. Client This issue points to a problem in the data-plane of the library. Service Bus Service Bus
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants