Record HttpSM Id on new transaction#5766
Conversation
| super::new_transaction(); | ||
|
|
||
| ink_release_assert(this->current_reader != nullptr); | ||
| this->_http_sm_id = this->current_reader->sm_id; |
There was a problem hiding this comment.
When H3 have Milestone/SlowLogs support.
There was a problem hiding this comment.
Then why not put it to the parent class? Are we not going to support it?
There was a problem hiding this comment.
The parent class is ProxyTransaction and it's also inherited by Http1Transaction. And Http1Transaction doesn't need this. Because Milestones for HTTP/1.1 is in HttpSM.
Milestones might be one thing of the refactoring SSN/TNX, but it's out of scope of this PR.
There was a problem hiding this comment.
The parent class is ProxyTransaction and it's also inherited by Http1Transaction. And Http1Transaction doesn't need this. Because Milestones for HTTP/1.1 is in HttpSM.
This doesn't sounds like a good design. It's inconsistent. I don't think we should follow it, otherwise things get worse.
Milestones might be one thing of the refactoring SSN/TNX, but it's out of scope of this PR.
I understand this PR is trying to fix a crash, but it seems like to me that you are unnecessarily adding a thing need to be refactored.
If you disagree, I can live with it but you need to find someone else to get an approval.
There was a problem hiding this comment.
I agree with Milestones, ProxyTransaction and HttpSM are not well designed.
But I don't want to do refactoring all of them here. Because 1) it might be huge changes 2) the refactoring HttpSM (#5488) is going on.
I'm fine with moving the assignment before the update_read_request() call instead of override new_transaction, if it looks simple.
There was a problem hiding this comment.
Who said you should refactor everything?
Moving _http_sm_id to ProxyTransaction and initializing it in ProxyTransaction::new_transaction() are enough, no? Will it be a huge change? I think this is much simpler than overriding a method and it is also a right direction (no need to additional refactoring).
There was a problem hiding this comment.
Now, I understand your suggestion. But I'm not big fun of adding a member which is not used by all child classes.
If we add the member on the ProxyTransaction, it's not used by Http1Transaction. Also if we derive Http(1|2|3)|ServerTransaction from ProxyTransaction, the _http_sm_id will not used by them. These relations of classes are really unclear for now.
There was a problem hiding this comment.
If we add the member on the ProxyTransaction, it's not used by Http1Transaction.
Currently true, and I think it should be changed later. Otherwise having it in a parent class doesn't make sense. Many things for H1 is currently too special because of historical reasons. I think new things should be designed more generically. Do you want to add another _http_sm_id to H3Transaction and override new_transaction again? I hope you don't forget to override it.
Also if we derive Http(1|2|3)|ServerTransaction from ProxyTransaction, the _http_sm_id will not used by them. These relations of classes are really unclear for now.
I'd rename ProxyTransaction to ClientProxyTransaction and define a new ProxyTransaction that have common parts. I don't think _http_sm_id is the only member we don't need for server side.
There is a path of Http2Stream::update_read_request() starts shutdown and make current_reader nullptr. Copying HttpSM Id from current_reader should be done before the update_read_request() call.
3cc26bf to
63150aa
Compare
After 0d2ad23 (#5747) merged, I intermittently faced below crash.
I thought accessing
Http2Stream::current_readerinHttp2Stream::send_request()is safe. But there is a path ofHttp2Stream::update_read_request()starts shutdown and make itnullptr.