[Refactor TaskAttribution] Rename |parent_task|Guohui Dengnit:
```suggestion
TaskAttribution: Rename |parent_task|
```
Done. I heavily edited the commit message due to new changes.
These variables are propogated from parents but they are just taskGuohui DengPlease fix this WARNING reported by Spellchecker: "propogated" is a possible misspelling of "propagated".
Analyzer Description: Checks for common typos.
Owner: chops-so...@google.com"propogated" is a possible misspelling of "propagated".
To bypass Spellchecker, add a footer with DISABLE_SPELLCHECKER
ditto.
// set the agent cluster ID to the embedder's, and nullify its parent task ID.Guohui Denghere too.
Done
transferable_message.task_id = std::nullopt;Guohui DengMaybe `task_attribution_id` (or alternatively `task_state_id`)? It would be nice to (fully) get away from the idea that tasks have IDs.
Yes and I used `task_state_id` in consistency with "task state".
// message's parent task ID.Guohui Dengnit: here too
Done
if (scheduler::TaskAttributionInfo* task = tracker->RunningTask()) {Guohui DengMaybe rename this one too?
Done
function_->SetTaskState(tracker->RunningTask());Guohui DengAs a follow-up, I wonder if we should rename this too now? Maybe `CurrentTaskState()` or something would be clearer?
Good idea and I appended this CL with this change.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
A couple of nits to improve comments, but this is great; thanks!
// The ID in the state of the task initiating the message.```suggestion
// The ID of the task state initiating the message.
```
// The state of the task that loaded the script.Maybe something like:
```suggestion
// The `TaskAttributionInfo` associated with the task that loaded the script.
```
?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// The ID in the state of the task initiating the message.```suggestion
// The ID of the task state initiating the message.
```
Done. I was trying to avoid saying the "task state initiating the message". I thought it's better to say "task"(instead of "task state") that "initiates the message". But something like the below is too verbose:
"The ID of the task state associated with the task initiating the message".
If you think any alternative is better, I will be happy to modify this CL accordingly.
Maybe something like:
```suggestion
// The `TaskAttributionInfo` associated with the task that loaded the script.
```?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// The ID in the state of the task initiating the message.Guohui Deng```suggestion
// The ID of the task state initiating the message.
```
Done. I was trying to avoid saying the "task state initiating the message". I thought it's better to say "task"(instead of "task state") that "initiates the message". But something like the below is too verbose:
"The ID of the task state associated with the task initiating the message".
If you think any alternative is better, I will be happy to modify this CL accordingly.
But something like the below is too verbose:
"The ID of the task state associated with the task initiating the message".
Actually this SGTM (I think it's clearer); can we use that?
Alternatively, something like "The TaskAttributionId of the task initiating the message, if any.", if you want to be less verbose?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// The ID in the state of the task initiating the message.Guohui Deng```suggestion
// The ID of the task state initiating the message.
```
Scott HaseleyDone. I was trying to avoid saying the "task state initiating the message". I thought it's better to say "task"(instead of "task state") that "initiates the message". But something like the below is too verbose:
"The ID of the task state associated with the task initiating the message".
If you think any alternative is better, I will be happy to modify this CL accordingly.
But something like the below is too verbose:
"The ID of the task state associated with the task initiating the message".
Actually this SGTM (I think it's clearer); can we use that?
Alternatively, something like "The TaskAttributionId of the task initiating the message, if any.", if you want to be less verbose?
I think "The TaskAttributionId ..." is the best! I used it.
I will request for more reviewers after you approve this CL.
Thanks!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This CL needs owners' approval. Thanks for reviewing.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
From googleclient/chrome/chromium_gwsq/ipc/config.gwsq:
IPC: dch...@chromium.org, ke...@chromium.org
📎 It looks like you’re making a possibly security-sensitive change! 📎 IPC security review isn’t a rubberstamp, so your friendly security reviewer will need a fair amount of context to review your CL effectively. Please review your CL description and code comments to make sure they provide context for someone unfamiliar with your project/area. Pay special attention to where data comes from and which processes it flows between (and their privilege levels). Feel free to point your security reviewer at design docs, bugs, or other links if you can’t reasonably make a self-contained CL description. (Also see https://cbea.ms/git-commit/).
IPC reviewer(s): dch...@chromium.org, ke...@chromium.org
Note: IPC gwsq added no new reviewers; existing reviewers satisfied requirements!
Reviewer source(s):
dch...@chromium.org is from context(googleclient/chrome/chromium_gwsq/ipc/config.gwsq)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
third_party/blink/public/common/messaging/transferable_message.h lgtm
You didn't specify which files I was to review, so if there are any others that need my attention, let me know.
| Code-Review | +1 |
Sorry I didn't specify exactly what files need owner review from who. There are still a few needs owner approval.
@ke...@chromium.org and @jon...@chromium.org: Would either of you owner review `render_frame_host_impl.cc`?
@wande...@meta.com and @yyana...@chromium.org: Would either of you owner review `content/browser/service_worker/`?
Thanks a lot.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
SW lgtm.
It actually set std::nullopt, and does not track.
My review isn't needed.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Thanks!
TaskAttribution: Rename variables and functions
"parent task" --> "task state"; "task id" --> "task state id";
"RunningTask" --> "CurrentTaskState"
The reasons are: 1) An instance of TaskAttributionInfo is a task state;
2) A "task id" is just part of a "task state" and we are moving away
from the concept of "task id"; 3) TaskAttributionTracker returns the
state of the task, not the task itself.
No behavior change is expected to result from this CL.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |