get all computing status at once when changing node#3796
Open
EtienneLt wants to merge 23 commits into
Open
Conversation
Signed-off-by: Etienne LESOT <etienne.lesot@rte-france.com>
…o use-allcomputationstatus-in-once
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds a new hook that fetches all computation statuses at once, maps raw values to RunningStatus, dispatches per-type status (and parameters), integrates the hook into existing status wiring, and adds backend helpers and a status-mapping utility. ChangesAll-at-once computing-status
Sequence DiagramsequenceDiagram
participant React as React Component
participant Hook as useAllComputingStatusAtOnce
participant Notif as Notifications Listener
participant API as Backend API (study.fetchAllComputationStatus)
participant Redux as Redux Store
React->>Hook: init(studyUuid,nodeUuid,rootNetworkUuid,fetcher)
Hook->>API: fetchAllComputationStatus(studyUuid,nodeUuid,rootNetworkUuid)
API-->>Hook: Map<ComputingType,string> (or throws)
Hook->>Hook: map each status -> RunningStatus (getComputationRunningStatus)
Hook->>Redux: dispatch setComputingStatus(type, status)
alt status has parameters && status != IDLE
Hook->>API: fetch per-type parameters (getComputingStatusParametersFetcher)
API-->>Hook: parameters
Hook->>Redux: dispatch setComputingStatusParameters(type, params)
end
Notif->>Hook: STUDY event
Hook->>Hook: evaluateUpdate (isWorthUpdate)
alt relevant
Hook->>Hook: trigger update -> repeat fetch flow
Hook->>Redux: dispatch setLastCompletedComputation when completion detected
end
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/components/computing-status/use-all-computing-status.ts`:
- Around line 311-317: Per-type hooks are still firing on node/root changes
because useComputingStatus's evaluateUpdate callback lists nodeUuid and
currentRootNetworkUuid in its dependency array; remove nodeUuid and
currentRootNetworkUuid from the dependency array in the evaluateUpdate
definition inside useComputingStatus so that evaluateUpdate (and its call to
update()/computingStatusFetcher) does not run on node/root changes;
alternatively, if you prefer selective mounting, change useAllComputingStatus to
skip mounting the per-type useComputingStatus hooks when
useAllComputingStatusAtOnce is used, but the simpler fix is to edit
useComputingStatus (evaluateUpdate) to depend only on the keys that should
trigger individual fetches (e.g., studyUuid) to avoid duplicate batched+per-type
requests.
In `@src/components/computing-status/use-computing-status-at-once.ts`:
- Around line 146-201: The catch block currently uses the outer canceledRequest
flag (and returns a cleanup that isn't consumed), so stale fetch rejections can
mark every ComputingType as FAILED; fix this by creating a request-scoped token
(e.g., a local requestId or an AbortController) at the start of the update flow
and pass it into allComputingStatusFetcher and handleComputingStatusParameters
(or check it before mutating state), then in the catch ensure you verify the
request token hasn't been superseded before dispatching setComputingStatus(...,
RunningStatus.FAILED); also collapse the per-computing-type console.error into a
single log outside the loop and avoid flipping canceledRequest from an unused
cleanup—use the token/ref to signal cancellation and compare against
nodeUuidRef/currentRootNetworkUuid if needed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 2b1f29da-d400-40a6-ab68-1e8d2594621f
📒 Files selected for processing (4)
src/components/computing-status/use-all-computing-status.tssrc/components/computing-status/use-computing-status-at-once.tssrc/components/computing-status/use-computing-status.tssrc/services/study/study.ts
💤 Files with no reviewable changes (1)
- src/components/computing-status/use-computing-status.ts
Signed-off-by: Etienne LESOT <etienne.lesot@rte-france.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/services/study/study.ts`:
- Around line 156-166: fetchAllComputationStatus currently declares
Promise<Map<ComputingType, string>> but backendFetchJson returns a plain object;
change fetchAllComputationStatus's return type to Promise<Record<ComputingType,
string>> (or equivalent {}) and update any consumers' types accordingly: replace
Map usages in UseComputingStatusProps and LastUpdateProps in
use-computing-status-at-once.ts with Record<ComputingType, string>, ensuring the
hook and its consumers use Object.entries/Object.keys rather than Map methods;
alternatively, if you prefer a Map at runtime, convert the returned object to a
Map inside fetchAllComputationStatus before returning and keep consumers
as-is—pick one consistent approach and update the signature of
fetchAllComputationStatus and the related interfaces to match.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 882b29ea-3bd5-4c2b-991a-e8c3f2ab86fc
📒 Files selected for processing (2)
src/components/computing-status/use-computing-status-at-once.tssrc/services/study/study.ts
Signed-off-by: Etienne LESOT <etienne.lesot@rte-france.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
src/services/study/study.ts (1)
134-137: Collapse duplicate short-circuit cases.
SHORT_CIRCUITandSHORT_CIRCUIT_ONE_BUSboth invokegetShortCircuitAnalysisRunningStatus(statusValue); a fallthrough removes duplication and makes intent clearer.♻️ Proposed fix
case ComputingType.SHORT_CIRCUIT: - return getShortCircuitAnalysisRunningStatus(statusValue); case ComputingType.SHORT_CIRCUIT_ONE_BUS: return getShortCircuitAnalysisRunningStatus(statusValue);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/services/study/study.ts` around lines 134 - 137, Two switch cases (ComputingType.SHORT_CIRCUIT and ComputingType.SHORT_CIRCUIT_ONE_BUS) call the same handler getShortCircuitAnalysisRunningStatus(statusValue); collapse them into a single branch by grouping the case labels (e.g., "case ComputingType.SHORT_CIRCUIT: case ComputingType.SHORT_CIRCUIT_ONE_BUS:") so only one return getShortCircuitAnalysisRunningStatus(statusValue) remains, removing the duplicated line in the switch inside study.ts.src/components/computing-status/use-computing-status-at-once.ts (1)
105-137: Redundant (and misleading) ref writes insidehandleComputingStatusParameters.Lines 110-111 reassign
nodeUuidRef.current/rootNetworkUuidRef.currentto thenodeUuid/currentRootNetworkUuidcaptured by thisuseCallbackclosure, which are the same values the refs were just set to inupdate()(Lines 147-148). The subsequentshouldRequestBeCanceledcheck at Lines 117-125 then compares the refs against those same closure values, so the only way it can trip is if a differentupdate()run mutates the refs between Lines 110-111 and Line 117 — but Lines 110-111 undo exactly that signal. In effect these two assignments weaken the race-detection mechanism thatisWorthUpdate/update()rely on. Drop them and letupdate()own the refs.♻️ Proposed fix
if ( computingStatusParametersFetcher && computationStatus !== RunningStatus.IDLE && isParameterizedComputingType(computingType) ) { - nodeUuidRef.current = nodeUuid; - rootNetworkUuidRef.current = currentRootNetworkUuid; const computingStatusParametersResult = await computingStatusParametersFetcher(🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/computing-status/use-computing-status-at-once.ts` around lines 105 - 137, In handleComputingStatusParameters remove the redundant assignments to nodeUuidRef.current and rootNetworkUuidRef.current (the lines that set them to nodeUuid and currentRootNetworkUuid) so the race-detection performed by update()/isWorthUpdate via those refs is not neutralized; rely on update() to own and set nodeUuidRef/rootNetworkUuidRef, keep the shouldRequestBeCanceled(...) call and the subsequent dispatch(setComputingStatusParameters(..., toComputingStatusParameters(...))) and the use of computingStatusParametersFetcher unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/components/computing-status/use-computing-status-at-once.ts`:
- Around line 168-185: The async callback passed to allStatusInfosMap.forEach
silently drops promises; replace the forEach with an explicit iteration that
properly awaits handleComputingStatusParameters so errors propagate to the
surrounding try/catch and ordering is deterministic. Locate the block that
builds allStatusInfosMap (allStatusInfosMap = new Map(...)) and the forEach
using getRunningStatusByComputingType, dispatch(setComputingStatus(...)),
isComputationCompleted/getCompletions and
handleComputingStatusParameters(canceledRequest,
getComputingStatusParametersFetcher(...)); change it to either a for...of loop
that awaits each call to handleComputingStatusParameters (so cancellation via
canceledRequest and subsequent guards observe completed work) or collect the
per-type promises into an array and await Promise.all(...) and rethrow on
failure so update() does not resolve early and the outer try/catch sees
rejections.
---
Nitpick comments:
In `@src/components/computing-status/use-computing-status-at-once.ts`:
- Around line 105-137: In handleComputingStatusParameters remove the redundant
assignments to nodeUuidRef.current and rootNetworkUuidRef.current (the lines
that set them to nodeUuid and currentRootNetworkUuid) so the race-detection
performed by update()/isWorthUpdate via those refs is not neutralized; rely on
update() to own and set nodeUuidRef/rootNetworkUuidRef, keep the
shouldRequestBeCanceled(...) call and the subsequent
dispatch(setComputingStatusParameters(..., toComputingStatusParameters(...)))
and the use of computingStatusParametersFetcher unchanged.
In `@src/services/study/study.ts`:
- Around line 134-137: Two switch cases (ComputingType.SHORT_CIRCUIT and
ComputingType.SHORT_CIRCUIT_ONE_BUS) call the same handler
getShortCircuitAnalysisRunningStatus(statusValue); collapse them into a single
branch by grouping the case labels (e.g., "case ComputingType.SHORT_CIRCUIT:
case ComputingType.SHORT_CIRCUIT_ONE_BUS:") so only one return
getShortCircuitAnalysisRunningStatus(statusValue) remains, removing the
duplicated line in the switch inside study.ts.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0fec6d32-94b3-4038-a24f-9eb4a95cceb8
📒 Files selected for processing (2)
src/components/computing-status/use-computing-status-at-once.tssrc/services/study/study.ts
Signed-off-by: Etienne LESOT <etienne.lesot@rte-france.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
src/components/computing-status/use-computing-status-at-once.ts (1)
98-145:⚠️ Potential issue | 🔴 CriticalCancellation flag is unreachable — already flagged previously.
updateAllisasync, so the cleanup returned at Lines 143–145 is wrapped in aPromiseand the call site at Line 163 (updateAll()) discards it;canceledRequesttherefore can never flip totrue, defeating both theshouldRequestBeCanceledguard and theif (!canceledRequest)check in thecatch. As a result, a stale rejection following a node/root switch will still mark everyComputingTypeasFAILED. Please replace the local flag with a request-scoped token (e.g. anAbortControlleror a counter compared againstnodeUuidRef/rootNetworkUuidRef) so cancellation actually takes effect.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/computing-status/use-computing-status-at-once.ts` around lines 98 - 145, The local canceledRequest boolean inside updateAll is ineffective because updateAll is async and its returned cleanup is discarded; replace this flag with a request-scoped cancellation token (for example create an AbortController per invocation or an incrementing requestId) and use that token in shouldRequestBeCanceled and the catch block to decide early returns and avoid marking all ComputingType as FAILED. Specifically, when starting updateAll create a new controller/requestId and store it in a local variable, pass its signal/id into the allComputingStatusFetcher call and change checks that reference canceledRequest, nodeUuidRef or rootNetworkUuidRef to consult the new token, and in the effect cleanup invoke controller.abort() or bump a shared requestId so stale async completions (used by setComputingStatus, setLastCompletedComputation, and the catch handling) no longer run for cancelled requests.
🧹 Nitpick comments (2)
src/components/computing-status/use-computing-status-at-once.ts (2)
49-62: Dead code inisWorthUpdatefallback.The early return at Lines 49–51 already returns
truewhenrootNetworkUuidRef.current !== currentRootNetworkUuid, so by the time execution reaches Line 61 those two values are guaranteed equal and the expression always evaluates tofalse. Replace with an explicitreturn false;(or drop the redundant comparison).♻️ Proposed simplification
- return rootNetworkUuidRef.current !== currentRootNetworkUuid; + return false;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/computing-status/use-computing-status-at-once.ts` around lines 49 - 62, The fallback in isWorthUpdate contains a redundant comparison: after the early return that checks rootNetworkUuidRef.current !== currentRootNetworkUuid, those values are equal, so the final "return rootNetworkUuidRef.current !== currentRootNetworkUuid" is dead code; replace that final return with an explicit "return false" (or simply remove the comparison and return false) inside the isWorthUpdate function to make intent clear and eliminate the unreachable expression.
92-92:lastUpdateRefis written but never read.The ref declared at Line 92 and assigned at Line 161 is never consumed anywhere in this hook. Either remove it (and the
LastUpdatePropstype at Lines 31–38) or wire it into the logic that needs the last event/fetcher snapshot. Carrying unused state adds noise and invites future confusion about its intent.Also applies to: 161-161
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/components/computing-status/use-computing-status-at-once.ts` at line 92, Remove the unused ref and its type: delete the declaration const lastUpdateRef = useRef<LastUpdateProps | null>(null), remove any assignment to lastUpdateRef.current, and delete the LastUpdateProps type definition; alternatively, if you intend to use it, wire lastUpdateRef into the hook’s output or logic (e.g., expose it via the return value of useComputingStatusAtOnce or read it where the hook needs the last event/fetcher snapshot) so that lastUpdateRef and its assignments are actually consumed. Ensure no remaining references to lastUpdateRef or LastUpdateProps remain after the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/components/computing-status/use-computing-status-at-once.ts`:
- Around line 133-141: The catch block currently logs the same error message
inside the per-type loop; move the logging out of the loop and log the full
error object (not just e?.message) so the error is emitted once with stack
trace. Specifically, in the catch where canceledRequest is checked, first
iterate Object.values(ComputingType) and call
dispatch(setComputingStatus(computingType, RunningStatus.FAILED)) for each
computingType, then after the loop call console.error(e) (or processLogger/error
helper) to log the full error object instead of logging inside the loop.
---
Duplicate comments:
In `@src/components/computing-status/use-computing-status-at-once.ts`:
- Around line 98-145: The local canceledRequest boolean inside updateAll is
ineffective because updateAll is async and its returned cleanup is discarded;
replace this flag with a request-scoped cancellation token (for example create
an AbortController per invocation or an incrementing requestId) and use that
token in shouldRequestBeCanceled and the catch block to decide early returns and
avoid marking all ComputingType as FAILED. Specifically, when starting updateAll
create a new controller/requestId and store it in a local variable, pass its
signal/id into the allComputingStatusFetcher call and change checks that
reference canceledRequest, nodeUuidRef or rootNetworkUuidRef to consult the new
token, and in the effect cleanup invoke controller.abort() or bump a shared
requestId so stale async completions (used by setComputingStatus,
setLastCompletedComputation, and the catch handling) no longer run for cancelled
requests.
---
Nitpick comments:
In `@src/components/computing-status/use-computing-status-at-once.ts`:
- Around line 49-62: The fallback in isWorthUpdate contains a redundant
comparison: after the early return that checks rootNetworkUuidRef.current !==
currentRootNetworkUuid, those values are equal, so the final "return
rootNetworkUuidRef.current !== currentRootNetworkUuid" is dead code; replace
that final return with an explicit "return false" (or simply remove the
comparison and return false) inside the isWorthUpdate function to make intent
clear and eliminate the unreachable expression.
- Line 92: Remove the unused ref and its type: delete the declaration const
lastUpdateRef = useRef<LastUpdateProps | null>(null), remove any assignment to
lastUpdateRef.current, and delete the LastUpdateProps type definition;
alternatively, if you intend to use it, wire lastUpdateRef into the hook’s
output or logic (e.g., expose it via the return value of
useComputingStatusAtOnce or read it where the hook needs the last event/fetcher
snapshot) so that lastUpdateRef and its assignments are actually consumed.
Ensure no remaining references to lastUpdateRef or LastUpdateProps remain after
the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 63a18ad5-6cb3-466a-8765-152e86fd8d6d
📒 Files selected for processing (3)
src/components/computing-status/use-all-computing-status.tssrc/components/computing-status/use-computing-status-at-once.tssrc/components/computing-status/use-computing-status.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- src/components/computing-status/use-all-computing-status.ts
- src/components/computing-status/use-computing-status.ts
|
SlimaneAmar
reviewed
May 12, 2026
| const status = getRunningStatusByComputingType(statusValue, computingType); | ||
| dispatch(setComputingStatus(computingType, status)); | ||
| }); | ||
| } |
Contributor
There was a problem hiding this comment.
Need to fetch computingStatusParameters ?
| if (updateType === 'buildCompleted' || updateType === 'all_computation_status') { | ||
| return true; | ||
| } | ||
| return rootNetworkUuidRef.current !== currentRootNetworkUuid; |
Contributor
There was a problem hiding this comment.
Already done this test
| if (!updateType) { | ||
| return false; | ||
| } | ||
| if (updateType === 'buildCompleted' || updateType === 'all_computation_status') { |
Contributor
Author
There was a problem hiding this comment.
it was present for one computation status
There was a problem hiding this comment.
♻️ Duplicate comments (2)
src/services/study/study.ts (1)
124-134:⚠️ Potential issue | 🔴 Critical | ⚡ Quick win
fetchAllComputationStatusdeclaresMapbut returns raw JSON object.
backendFetchJson(url)won’t materialize aMap; it returns parsed JSON. With the current signature, downstreamMap.forEach(...)can fail at runtime when the payload is a plain object. Please either convert here toMapor switch the contract toRecord<ComputingType, string>consistently.#!/bin/bash # Verify backendFetchJson behavior and current status-shape usage. set -euo pipefail echo "== backendFetchJson definition(s) ==" rg -n -C3 '\bbackendFetchJson\b' --type ts echo echo "== fetchAllComputationStatus implementation ==" rg -n -C5 'export function fetchAllComputationStatus|backendFetchJson\(url\)' src/services/study/study.ts echo echo "== all-at-once hook consumption shape (Map vs object) ==" rg -n -C5 'allComputingStatusFetcher|computingStatusesResult|forEach\(|Object\.entries\(' src/components/computing-status/use-computing-status-at-once.ts🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/services/study/study.ts` around lines 124 - 134, fetchAllComputationStatus currently types its return as Promise<Map<ComputingType,string>> but simply returns backendFetchJson(url) which yields a plain object; convert the payload to a Map before returning or change the function signature to Promise<Record<ComputingType,string>> to match backendFetchJson. Locate fetchAllComputationStatus and either (A) call backendFetchJson(url) then build and return new Map(Object.entries(json) as [ComputingType,string][]) or (B) update the return type to Promise<Record<ComputingType,string>> and leave the raw json passthrough, and then update any consumers (e.g., use-computing-status-at-once or any forEach usage) to use Object.entries/for..of or convert to Map there to avoid runtime errors.src/components/computing-status/use-computing-status-at-once.ts (1)
94-142:⚠️ Potential issue | 🟠 Major | ⚡ Quick winUse a request-scoped cancellation/token check in the
catchpath before broadcastingFAILED.
canceledRequesthere is not effective (the returned cleanup is never consumed), so an older rejected request can still set everyComputingTypetoFAILEDafter a node/root switch. Apply the same “request still current?” guard incatchusing a request id orAbortController, and log the error once outside the loop.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/computing-status/use-computing-status-at-once.ts` around lines 94 - 142, The catch path currently uses canceledRequest (whose cleanup is unused) so a stale rejected request can still broadcast FAILED; to fix, make the request cancellable/scoped inside updateAll by generating a per-call token (e.g., const requestId = Symbol() or use an AbortController) and store it in a shared ref before calling allComputingStatusFetcher, then in both the success path and the catch path check shouldRequestBeCanceled-like logic (or compare the stored ref token) before dispatching setComputingStatus for each ComputingType to RunningStatus.FAILED; also log the caught error once (outside the loop) instead of console.error inside the loop.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@src/components/computing-status/use-computing-status-at-once.ts`:
- Around line 94-142: The catch path currently uses canceledRequest (whose
cleanup is unused) so a stale rejected request can still broadcast FAILED; to
fix, make the request cancellable/scoped inside updateAll by generating a
per-call token (e.g., const requestId = Symbol() or use an AbortController) and
store it in a shared ref before calling allComputingStatusFetcher, then in both
the success path and the catch path check shouldRequestBeCanceled-like logic (or
compare the stored ref token) before dispatching setComputingStatus for each
ComputingType to RunningStatus.FAILED; also log the caught error once (outside
the loop) instead of console.error inside the loop.
In `@src/services/study/study.ts`:
- Around line 124-134: fetchAllComputationStatus currently types its return as
Promise<Map<ComputingType,string>> but simply returns backendFetchJson(url)
which yields a plain object; convert the payload to a Map before returning or
change the function signature to Promise<Record<ComputingType,string>> to match
backendFetchJson. Locate fetchAllComputationStatus and either (A) call
backendFetchJson(url) then build and return new Map(Object.entries(json) as
[ComputingType,string][]) or (B) update the return type to
Promise<Record<ComputingType,string>> and leave the raw json passthrough, and
then update any consumers (e.g., use-computing-status-at-once or any forEach
usage) to use Object.entries/for..of or convert to Map there to avoid runtime
errors.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7cc746da-df29-443b-b40b-aaca7a64bc68
📒 Files selected for processing (4)
src/components/computing-status/use-all-computing-status.tssrc/components/computing-status/use-computing-status-at-once.tssrc/components/utils/running-status.tssrc/services/study/study.ts
💤 Files with no reviewable changes (1)
- src/components/computing-status/use-all-computing-status.ts
klesaulnier
reviewed
May 20, 2026
| }; | ||
|
|
||
| /** | ||
| * this hook loads <computingType> state into redux, then keeps it updated according to notifications |
Contributor
There was a problem hiding this comment.
improve comment to make it different from "src/components/computing-status/use-computing-status.ts"
Signed-off-by: Etienne LESOT <etienne.lesot@rte-france.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Summary