Skip to content

[Bug] Do not try to initialize the TableClient if the service is disabled #11195

New issue

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

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

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from

Conversation

liliankasem
Copy link
Member

Issue describing the changes in this PR

resolves #11194

Pull request checklist

IMPORTANT: Currently, changes must be backported to the in-proc branch to be included in Core Tools and non-Flex deployments.

  • Backporting to the in-proc branch is not required
    • Otherwise: Link to backporting PR
  • My changes do not require documentation changes
    • Otherwise: Documentation issue linked to PR
  • My changes should not be added to the release notes for the next release
    • Otherwise: I've added my notes to release_notes.md
  • My changes do not need to be backported to a previous version
    • Otherwise: Backport tracked by issue/PR #issue_or_pr
  • My changes do not require diagnostic events changes
    • Otherwise: I have added/updated all related diagnostic events and their documentation (Documentation issue linked to PR)
  • I have added all required tests (Unit tests, E2E tests)

Additional information

Do not try to initialize the TableClient if the service is disabled.

@liliankasem liliankasem requested a review from a team as a code owner July 18, 2025 18:28
{
_flushLogsTimer?.Value?.Dispose();
}

FlushLogs().GetAwaiter().GetResult();
if (_tableClient is not null)
Copy link
Member

Choose a reason for hiding this comment

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

It seems like an abuse to reference the field here, when the intent of the TableClient property is to ensure all usages go through the property.

Perhaps Dispose should just set _isEnabled to false, or call DisableService, which would cause FlushLogs to noop?

Copy link
Member Author

Choose a reason for hiding this comment

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

I did originally start with _isEnabled = false but we opted not to use that approach because of Fabio's comment: #11195 (comment)

This introduces a change in behavior and potential data loss if this was running properly (a client was already created) and logs were buffered.

The TableClient propery is overloaded and we have another issue to refactor the whole thing. This is patch in the meantime to address this bug #11194

Copy link
Member

Choose a reason for hiding this comment

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

Agreed, not an ideal pattern/fix, but I'm OK with us doing this if we're tracking a longer-term change.

Copy link
Member

Choose a reason for hiding this comment

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

ok

Copy link
Member

@fabiocav fabiocav left a comment

Choose a reason for hiding this comment

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

Commented above. I'm OK with the change, but let's have a test in place to validate the behavior with the changes in place.

@liliankasem
Copy link
Member Author

Discussed with Fabio and as we already have a solution for the core tools problem, we will close this PR in favour of a fixing the real issue with the TableClient property:

#11198

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.

DiagnosticEventTableStorageRepository: TableClient initialization occurs even after host shutdown
5 participants