Just wondering if I'm misunderstanding something or if there might be a small error in the SDK.
In GS.CPP line 440 in ProcessReceivedRepsonse (sic) the code checks (requests.GetDurableRetrySecond() > 0) but ALL GSRequests set m_DurableRetrySeconds to 1 by default so this code always triggers even when the request isn't set as durable. (It's also not clear to me how that function is even called since it's in the private section of GSRequest)
It happens to not seem to have any bad side effects because RemoveDurableQueueEntry() just doesn't do anything since the request isn't in the durable queue, but it seems odd that every message is treated like it was durable.
Thanks.
1 Comment
Customer Support
said
over 7 years ago
Thanks for the heads-up Steven, this issue has been fixed. m_DurableRetrySeconds is now set to 0.
Steven Ritchie
Just wondering if I'm misunderstanding something or if there might be a small error in the SDK.
In GS.CPP line 440 in ProcessReceivedRepsonse (sic) the code checks (requests.GetDurableRetrySecond() > 0) but ALL GSRequests set m_DurableRetrySeconds to 1 by default so this code always triggers even when the request isn't set as durable. (It's also not clear to me how that function is even called since it's in the private section of GSRequest)
It happens to not seem to have any bad side effects because RemoveDurableQueueEntry() just doesn't do anything since the request isn't in the durable queue, but it seems odd that every message is treated like it was durable.
Thanks.