I think that's related to the rounding errors one can get with doubles. Without parallelization, the rounding error is consistent, whereas with parallelization there is a degree of randomization, but neither is correct. If you do this with decimals instead of doubles, you consistently get the result 228,150,401.25. This is because the decimal type is explicitly designed to avoid rounding errors. We can verify this is the correct result by looking at the Sum() and Count() of the results, which are: 114,075,200,625,000,000 500,000,000 Cancelling the zeros gives: 114,075,200,625 500 I'm not going to do the full long division, but it's evident this ends in exactly .25.

@@CodingTutorialsAreGo Yes it is related the rounding errors one can get with doubles . If you chunk the list depending on the chunks and their order you wont get nécessarily the exact same result . Thank you

The 'results' array has to be pre-allocated to the number of results, which in this case, we happen to know. In other circumstances, we might not know the final size, and if we want the collection to expand to fit, it has to be thread safe.

@@CodingTutorialsAreGo clear thank you

The way I'd do it would be to put the token in a variable, then use the variable in the authentication header for the request. Then you just have to cut and paste the token value from the login response to the variable.

@@CodingTutorialsAreGo thank you for your response but I think it would be better if we could send the login request and then store it in a variable for the later request (similar to Postman)

Sorry, I don't understand the question.

Which is exactly what you don't want to do. You do not want to return 0 because that is not the correct result. And if the cancellation happened later, you would get a non-zero value that was still not the correct result. How would the client code know? You need to throw an exception to indicate that the calculation did not complete.

​@@CodingTutorialsAreGo , good point, thanks for bringing my attention to this , and what i actually mean depend on the case . if the user ( Cancel the task ) vs ( he EXITs the Window ) , when Existing there is no longer " telling the user where did he stop " in this case we force the Cancellation at the closest point and Dispose everything . unless you want the user to continue his task from where did he stop if he launch the ( application / task ) again . if so that's another topic related to Cashing, something you may need in applications like "Internet download manager" where you want the user to have the ability to keep downloading from the same percentage he stop at even if the application exists or crashed .

You would need to store multiple refresh tokens in the DB.

Thanks 👍

Yes, the fetch will still work because the JWT is stored in session storage and the session persists for the lifetime of the tab. So a refresh within the tab doesn't lose the JWT.

I've never seen that done. I'm not sure the idea of requiring the client to refresh within a time limit is a very good idea. It would require the client software to be running a timer, which obviously wouldn't work if the client shutdown (which also would lose tokens in session storage, but not local storage). Even if the client did stay up it would mean unnecessary transmission and refreshes of tokens, when the client code decided to update but the user didn't, which would be a potential security compromise.

@@CodingTutorialsAreGo the scenario I am talking is exactly that. In which, the client code will pop up a modal with a timer that tells the user “hey, you have X seconds/minutes left to stay up in the session. Would you like to extend your session?” And if the timer reaches to the 0 seconds, then it would automatically logs out the user. This leads me to a second question. How to invalidate the JWT when the user logs out and the JWT is still valid? The client might erase the token from cookie or local storage but as you mentioned it could be stolen for example, a man in the middle attack. Thanks Jasper!

@@diegomelgar2696 That's one of the key things about JWTs - they cannot be invalidated, whereas refresh tokens can. That's why we have JWTs with a short expiry and refresh tokens with a longer one. I say they cannot be invalidated. You could make it so that the server holds a list of invalid JWTs which it rejects if they are used, but that's not the intended approach.

@@CodingTutorialsAreGo nice, thank you for your time and explanation Jasper!!