Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

HostingBackgroundService should wait for StorageInitialized #3333

Merged
merged 1 commit into from
Jun 15, 2023

Conversation

brendankowitz
Copy link
Member

@brendankowitz brendankowitz commented Jun 6, 2023

Description

HostingBackgroundService should wait for StorageInitializedNotification, jobs that require QueueClient (all) or any data access should respect this. This allows all job tasks to inherit this behavior.

@PTaladay, @LTA-Thinking

FHIR Team Checklist

  • Update the title of the PR to be succinct and less than 65 characters
  • Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
  • Tag the PR with the type of update: Bug, Build, Dependencies, Enhancement, New-Feature or Documentation
  • Tag the PR with Open source, Azure API for FHIR (CosmosDB or common code) or Azure Healthcare APIs (SQL or common code) to specify where this change is intended to be released.
  • CI is green before merge Build Status
  • Review squash-merge requirements

Semver Change (docs)

Patch|Skip|Feature|Breaking (reason)

@brendankowitz brendankowitz requested a review from a team as a code owner June 6, 2023 17:52
@brendankowitz brendankowitz added the Enhancement-Refactor Refactor on existing functionality. label Jun 6, 2023
@brendankowitz brendankowitz added this to the S116 milestone Jun 6, 2023
@brendankowitz brendankowitz added Azure API for FHIR Label denotes that the issue or PR is relevant to the Azure API for FHIR Azure Healthcare APIs Label denotes that the issue or PR is relevant to the FHIR service in the Azure Healthcare APIs labels Jun 6, 2023
@brendankowitz brendankowitz changed the title HostingBackgroundService should wait for StorageInitializedNotification HostingBackgroundService should wait for StorageInitialized Jun 6, 2023
{
EnsureArg.IsNotNull(jobFactories, nameof(jobFactories));

_jobFactoryLookup = new Dictionary<int, Func<IJob>>();

foreach (Func<IJob> jobFunc in jobFactories)
{
var instance = jobFunc.Invoke();
if (instance.GetType().GetCustomAttribute(typeof(JobTypeIdAttribute), false) is JobTypeIdAttribute jobTypeAttr)
try
Copy link
Contributor

Choose a reason for hiding this comment

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

Why wrap this in a try/catch here? This looks like it would allow the JobFactory to be created successfully without all of the job types successfully added. This should be caught during testing as the affected job type wouldn't run, but I don't see why we would want this to succeed if there are broken job types.

Copy link
Member Author

@brendankowitz brendankowitz Jun 7, 2023

Choose a reason for hiding this comment

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

What I found was, the Queues determine the job types that are needed, Job Types can be registered that aren't used. In this examples Import was in core and registered, but this isn't ever used by a Cosmos instance. Stands to reason that if it is registered is should function, I'll change this to a throw

@brendankowitz brendankowitz force-pushed the personal/bkowitz/jobhost-storagenotifications branch 2 times, most recently from fc44b6c to 4cd2169 Compare June 7, 2023 15:08
LTA-Thinking
LTA-Thinking previously approved these changes Jun 7, 2023
@brendankowitz brendankowitz force-pushed the personal/bkowitz/jobhost-storagenotifications branch from 4cd2169 to 27bb0ce Compare June 8, 2023 15:19
@brendankowitz brendankowitz merged commit 40318f5 into main Jun 15, 2023
@brendankowitz brendankowitz deleted the personal/bkowitz/jobhost-storagenotifications branch June 15, 2023 21:48
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Azure API for FHIR Label denotes that the issue or PR is relevant to the Azure API for FHIR Azure Healthcare APIs Label denotes that the issue or PR is relevant to the FHIR service in the Azure Healthcare APIs Enhancement-Refactor Refactor on existing functionality.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants