fix: [sessiond] only unsuspend credits that have non 0 quota#7037
fix: [sessiond] only unsuspend credits that have non 0 quota#7037themarwhal merged 1 commit intomagma:masterfrom
Conversation
|
Thanks for opening a PR! 💯 Please note that all commits must be signed off. This is enforced by the Howto
More infoPlease take a moment to read through the Magma project's
If this is your first Magma PR, also consider reading
|
0371cd2 to
aee40b2
Compare
e7ee635 to
7a5d793
Compare
uri200
left a comment
There was a problem hiding this comment.
note that there is a difference of being suspended and being with credit 0
If we receive credit, but the credit is 0 and we generate traffic, I guess our session should be terminated.
However, with those changes we will keep the session.
So imagine a situation were the subscriber does not have data anymore, PCRF keeps sending grants 0 (not sure if the PCRF would be so dumb), but the subscriber is never allowed to leave.
Not sure if this situation is even possible, but maybe worth thinking on it before landing this
Yeah well this case is it is already suspended AND credit is 0. I think in this case we don't want to unsuspend the credit even if the OCS keeps sending 0. Although the case we might not handling might be:
I think in this case hopefully we terminate the session. But who knows :D I'll write a unit test and see what happens in that case. |
7a5d793 to
965a2a8
Compare
c83ab2a to
8a04f03
Compare
8a04f03 to
515df91
Compare
e39db86 to
f3ce648
Compare
f3ce648 to
8b5216e
Compare
7c1ae36 to
6c8fc4c
Compare
| << " for " << session_id << " during update. Not action taken"; | ||
| } | ||
| return true; | ||
| } |
There was a problem hiding this comment.
I remember I tried with a similar function and I felt that the function was mixing too many things, doing stuff in some objects, and returning a value. That is why I prefered to had the logic on update_charging_credits
There was a problem hiding this comment.
Yeah it's a bit opaque but tried to make it so that the boolean value returned just indicates whether we want to further process the credit or not.
The update_charging_credits function was getting too long/ hard to read :/
There was a problem hiding this comment.
I can add a comment on the line where we call the function too, if that helps with clarity.
There was a problem hiding this comment.
yes, maybe a comment will help us in the future.
| } | ||
| if (grant->should_deactivate_service()) { | ||
| grant->set_service_state(SERVICE_NEEDS_DEACTIVATION, credit_uc); | ||
| } |
There was a problem hiding this comment.
why do we check it here. Don't we have to wait for the next cycle to check?
There was a problem hiding this comment.
@uri200 This case will only cover the case where the credit is already exhausted and FUA-terminate is set. Since at this point no new usage is added, it just acts on the terminate instruction.
(I don't think it makes much sense to wait until the next cycle in this case)
|
I would recommend to run this on TeraVM with tests (5 is gy credit, and 6 is gx monitors) example |
6c8fc4c to
84a8d73
Compare
Signed-off-by: Marie Bremner <[email protected]>
84a8d73 to
d34e56d
Compare
|
is this getting backported to 1.5? 1.4? |
@talkhasib yes, but it takes a bit of work. Will put up a PR against 1.5 tomorrow. (Will have to see how difficult backporting to 1.4 will be) |
Lets only backport to 1.5 for now |
Signed-off-by: Marie Bremner <[email protected]>
Signed-off-by: Marie Bremner <[email protected]>
) Signed-off-by: Marie Bremner <[email protected]>
…7139) Signed-off-by: Marie Bremner <[email protected]>
) Signed-off-by: Ramon Melero <[email protected]>
) (magma#7139) Signed-off-by: Marie Bremner <[email protected]>
) (magma#7139) Signed-off-by: Marie Bremner <[email protected]>

Summary
See attached issue for the reported problem.
In short, we have to make sure that a credit has >0 quota before un-suspending.
We currently only check for these two things:
But since we could receive a valid credit with 0 grant, we should also check that the there is quota available.
The logic is slightly messy as we handle 'suspended' credits slightly differently from credits that have been deactivated due to FUA-redirect/restrict.
In order to make this work, I've had to make two changes:
When determining whether to remove Gy rules, check that the credit needs to be activated. This is done by the logic check:
When receiving a new credit, determine if the credit needs to be deactivated. We didn't check for this before, but this is useful for the edge case where we receive a FUA-terminate for an already empty quota.
Unit tests added
test_no_credit_reauth_with_redirected_suspended_credit(fails on master w/o the changes)test_terminate_credit_reauth_with_redirected_suspended_credit(fails on master w/o the changes)Test Plan
make precommit_sm
the new unit test fails on master w/o this change
Additional Information