Skip to content

#239 - fix portal ensemble submission timing issue#251

Merged
markcoletti merged 2 commits into
0.9.0-prereleasefrom
239-fix_portal_timing_issue
Jul 14, 2026
Merged

#239 - fix portal ensemble submission timing issue#251
markcoletti merged 2 commits into
0.9.0-prereleasefrom
239-fix_portal_timing_issue

Conversation

@Lance-Drane

Copy link
Copy Markdown

This adds a universal subscription channel for all components to solve the timing issue problem. This also fixes the portal bridge logic to continuously poll for responses back from the Portal Data API, which is important for blocking tasks. Currently we only care about confirmation that the ensemble values were uploaded, the notebook + data APIs should be able to remain entirely asynchronous for now.

The basic logic:

  • have a flag which is set to False by default
  • when the run_ensemble API needs to wait for confirmation from the Portal, wait in a loop for the flag to be set to True
  • set the flag to True in the callback function (which is separate from the run_ensemble API)
  • after verifying that the flag was set to True, immediately set the flag back to False so that the run_ensemble API can be used again

The subscription channel can be derived from f'_IPS_{self.__component_id.get_serialization()}' (need to have the _IPS_ prefix or else the logic in the services' subscribe function will add additional prefixes, which aren't desirable ; importantly, the subscription happens in the __run__ function of the Component class, which is never intended to be overridden by user code (unlike the init, step, terminate, finalize functions).

this adds a universal subscription channel for all components to solve this problem

Signed-off-by: Lance-Drane <Lance-Drane@users.noreply.github.com>
@Lance-Drane
Lance-Drane requested a review from markcoletti July 10, 2026 02:17
Signed-off-by: Lance-Drane <Lance-Drane@users.noreply.github.com>
@markcoletti markcoletti self-assigned this Jul 14, 2026
except MaxRetryError as e:
fail_count += 1
conn.send((999, f'Max retry error: {e}'))
conn.send((NOTEBOOK_MESSAGE_TYPE, next_val['component_id'], 999, f'Max retry error: {e}'))

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm concerned about the magic numbers 999 and -1.

@markcoletti markcoletti left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, though at some point we should probably make those magic numbers named constants.

@markcoletti
markcoletti merged commit 7e57982 into 0.9.0-prerelease Jul 14, 2026
0 of 13 checks passed
@markcoletti
markcoletti deleted the 239-fix_portal_timing_issue branch July 14, 2026 15:46
@markcoletti

Copy link
Copy Markdown

As stated in an associated comment, we should probably grep through the code and replace magic numbers with named constants or enumerated type values. Not a priority at this point, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants