🚨🚨 Source Instagram: upgrade to v18

[artem1205]

What

Resolve #33899

How

upgrade to v18

Recommended reading order

1. airbyte-integrations/connectors/source-instagram/setup.py
2. streams.py

🚨 User Impact 🚨

Reauthentication for all users required, scope added: business_management
see https://github.com/airbytehq/airbyte-platform-internal/pull/10582

• Stream Media Insights

  Old metric	New metric
  carousel_album_engagement	total_interactions
  carousel_album_impressions	impressions
  carousel_album_reach	reach
  carousel_album_saved	saved
  carousel_album_video_views	video_views
  engagement	total_interactions

  New metrics for Reels: ig_reels_avg_watch_time, ig_reels_video_view_total_time

• Stream UserLifetimeInsights

  Metric audience_locale become unavailable.
  Metrics audience_city, audience_country and audience_gender_age changed to one metric follower_demographics with respective breakdowns city, country, age,gender.
  primary key changed to ["business_account_id", "breakdown"]
  date property deleted.
  Metric type set to total_value, see docs for more info.

• Stream StoryInsights
  deprecated metrics: exits, taps_forward, taps_back

Pre-merge Actions

Updating a connector

Community member or Airbyter

• Grant edit access to maintainers (instructions)
• Unit & integration tests added

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

• Create a non-forked branch based on this PR and test the below items on it
• Build is successful
• If new credentials are required for use in CI, add them to GSM. Instructions.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
airbyte-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 5, 2024 10:51pm

[github-actions]

Before Merging a Connector Pull Request

Wow! What a great pull request you have here! 🎉

To merge this PR, ensure the following has been done/considered for each connector added or updated:

• PR name follows PR naming conventions
• Breaking changes are considered. If a Breaking Change is being introduced, ensure an Airbyte engineer has created a Breaking Change Plan.
• Connector version has been incremented in the Dockerfile and metadata.yaml according to our Semantic Versioning for Connectors guidelines
• You've updated the connector's metadata.yaml file any other relevant changes, including a breakingChanges entry for major version bumps. See metadata.yaml docs
• Secrets in the connector's spec are annotated with airbyte_secret
• All documentation files are up to date. (README.md, bootstrap.md, docs.md, etc...)
• Changelog updated in docs/integrations/<source or destination>/<name>.md with an entry for the new version. See changelog example
• Migration guide updated in docs/integrations/<source or destination>/<name>-migrations.md with an entry for the new version, if the version is a breaking change. See migration guide example
• If set, you've ensured the icon is present in the platform-internal repo. (Docs)

If the checklist is complete, but the CI check is failing,

1. Check for hidden checklists in your PR description

2. Toggle the github label checklist-action-run on/off to re-run the checklist CI.

[maxi297]

This seems on the right track but I lack information to approve. Can you answer those questions?

[maxi297]

I don't have any sample response from the previous version so I can't confirm what date really was. However, if the value was being updated every sync, it would mean that there was a new entry created in the destination every time. This will not be the case anymore. Is this an issue? Should we document this behavior change?

[artem1205]

You could find previous version here
This is an issue, because data will be returned for ALL period, see https://github.com/airbytehq/airbyte/pull/33930/files#diff-ade20df2f7ea130a82ed265a6a96eb70c0d9ccb98e92bb61afdb5b05c146525fR33

[maxi297]

So basically, we are moving from metric_type=time_series to metric_type= total_value, right? If so, is this what the customer wants? This seems like a different stream entirely

[artem1205]

Not really, we'll receive the most similar metrics as it was described in FB docs (alternative metric)

[maxi297]

Yes but they are not over time right?

[artem1205]

No, they are "lifetime", just 1 record per metric without any date.

[maxi297]

Now yes, but before, "date" was part of the primary key right? So we could have multiple entries in the database for the same metric (depending on the date)

[maxi297]

Sync discussion summary: The metric does not support time_series. So this is a breaking change and we don't have an easy way around it. We're fine with the change and will try to intercept user feedback if this is not good enough. In the meanwhile, @artem1205 will document the change better in the migration guide.

[maxi297]

LGTM!

[katmarkham]

please add link to migration guide and make other changes requested