Skip to content
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

fetch reports in bulk from couch #34563

Merged
merged 8 commits into from May 14, 2024
Merged

fetch reports in bulk from couch #34563

merged 8 commits into from May 14, 2024

Conversation

snopoke
Copy link
Contributor

@snopoke snopoke commented May 7, 2024

Technical Summary

Fetch the report docs from couch in bulk instead of one at a time. In some DD traces I noticed that each fetch from couch was taking ~300ms which stacks up for multiple reports. The bulk fetch should be much faster than successive individual fetches.

One other change is to check a FF outside of the per-row loop. In practice this is a locmem lookup but it still seems better to do it once instead of for every row.

Easiest review by commit (last commit is only lint).

Safety Assurance

Safety story

Covered by existing unit tests.

Automated test coverage

Existing coverage

QA Plan

None

Rollback instructions

  • This PR can be reverted after deploy with no further considerations

Labels & Review

  • Risk label is set correctly
  • The set of people pinged as reviewers is appropriate for the level of risk of the change

@snopoke snopoke added the product/invisible Change has no end-user visible impact label May 7, 2024
@snopoke snopoke requested review from esoergel and gherceg May 7, 2024 12:34
@snopoke snopoke requested a review from orangejenny as a code owner May 7, 2024 12:34
Copy link
Contributor

@esoergel esoergel left a comment

Choose a reason for hiding this comment

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

Good finds! Couple nits, nothing blocking

corehq/apps/app_manager/fixtures/mobile_ucr.py Outdated Show resolved Hide resolved
def fetch_reports(self, domain, report_configs):
"""Bulk fetch all reports for syncing"""
report_ids = [config.report_id for config in report_configs]
self.reports = _get_reports_and_data_source(report_ids, domain)
Copy link
Contributor

Choose a reason for hiding this comment

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

There's a weird ordering dependency here around setting self.reports that would be nice to avoid if doable. Would it be possible to make report_configs and domain required parameters to __init__, and then make self.reports a cached_property? I think that'd mean moving the initialization from BaseReportFixtureProvider.__init__ to __call__.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added a few commits to update this:

  1. pass all report configs to cache from the start
  2. still call 'load' in the fixture provider to allow for error handling
  3. load reports just in time if needed (purely a safeguard)
  4. allow loading a subset of the reports to avoid loading unnecessary reports in the V2 only use case.

Copy link
Contributor

Choose a reason for hiding this comment

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

thanks, looks great!

@snopoke snopoke merged commit ee8f9dc into master May 14, 2024
13 checks passed
@snopoke snopoke deleted the sk/mobile-ucr-tweaks branch May 14, 2024 15:20
Copy link

sentry-io bot commented May 14, 2024

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

  • ‼️ ReportConfigurationNotFoundError /hq/admin/phone/restore/ View Issue
  • ‼️ ReportConfigurationNotFoundError /hq/admin/phone/restore/ View Issue
  • ‼️ ReportConfigurationNotFoundError /a/{domain}/phone/restore/{app_id}/ View Issue

Did you find this useful? React with a 👍 or 👎

@esoergel
Copy link
Contributor

That sentry error is real and it is new as of this PR, but it's essentially just a different manifestation. This scenario would previously raise an error like this:
https://dimagi.sentry.io/issues/2850327813/

@snopoke
Copy link
Contributor Author

snopoke commented May 15, 2024

That sentry error is real and it is new as of this PR, but it's essentially just a different manifestation. This scenario would previously raise an error like this: https://dimagi.sentry.io/issues/2850327813/

👍🏻 the error seems like it must be an artifact of linked domains

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
product/invisible Change has no end-user visible impact
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants