How to silence "Missing sentry configuration properties"

[SleeplessByte]

Summary

Our expo projects are still using app.json and thus environment variables and secrets cannot be directly injected into the app.json. We're using sentry in many different ways and use a different (official) way to configure sentry via a configuration file that is not checked into the repository.

Since upgrading, when running expo for web, the console is littered with warnings about sentry not being configured correctly, despite it being disabled in DEV mode in the first place, AND actually being configured correctly.

The following messages shows up ~40 times on initial launch, and is reprinted several time each time HMR/refresh runs:

» android: sentry-expo: Missing Sentry configuration properties: authToken from app.json. Builds will fall back to environm
ent variables. Refer to @sentry/react-native docs for how to configure this.
» ios: sentry-expo: Missing Sentry configuration properties: authToken from app.json. Builds will fall back to environment 
variables. Refer to @sentry/react-native docs for how to configure this.

How can we turn these off without patch-packaging? I wouldn't mind it if the warning showed up once, but right now it's a ridiculous amount of times.

I selected managed as we're using expo build:web (and eas for native)

Managed or bare workflow? If you have ios/ or android/ directories in your project, the answer is bare!

managed

What platform(s) does this occur on?

Web

SDK Version (managed workflow only)

45

Environment

The expo diagnostics command is deprecated, use npx expo-env-info instead.

expo-env-info 1.0.3 environment info:
    System:
      OS: Windows 10 10.0.22000
    Binaries:
      Node: 16.13.0 - ~\scoop\apps\nvm\current\nodejs\nodejs\node.EXE
      Yarn: 1.22.18 - ~\scoop\apps\yarn\current\bin\yarn.CMD
      npm: 8.3.0 - ~\scoop\apps\nvm\current\nodejs\nodejs\npm.CMD
    npmPackages:
      @expo/webpack-config: ~0.16.24 => 0.16.24
      expo: ^45.0.4 => 45.0.4
      react: 17.0.2 => 17.0.2
      react-dom: 17.0.2 => 17.0.2
      react-native: 0.68.2 => 0.68.2
      react-native-web: 0.17.7 => 0.17.7
    Expo Workflow: managed

Reproducible demo or steps to reproduce from a blank project

1. Create a new project
2. Add sentry-expo
3. Configure like this:

{
  // ...
  "hooks": {
    "postPublish": [
      {
        "file": "sentry-expo/upload-sourcemaps",
        "config": {
          "organization": "...",
          "project": "..."
        }
      }
    ]
  },
  // ...
}

And like this:

"plugins": [
  // ...
  "sentry-expo",
  // ...
]

Configure sentry via ENV variables or sentry.properties

[sreuter]

Same here. Not sure what's wrong about getting the token from the environment.

[NoWay1201]

Same for me. I intentionally want configuration to be coming from environment and it keeps popping that.

[robertbossaert]

I don't know the specifics of your configuration but would a app.config.js be an option? as per these instructions: https://docs.expo.dev/workflow/configuration/ this would be a file you have alongside your app.json, you could use it to read environment variables.

[SleeplessByte]

No, our build pipeline replaces app.json (and has been in place from before app.not-json has been a thing).

It really shouldn't pollute the log like this, regardless of the warning.

[robertbossaert]

Okay... well for the other people above and anyone else reading this in the future; I had the same warning and fixed it using the app.config.js way above.

[Codelica]

Expo literally lets you create "Secrets" to pass sensitive info to your build environment (outside of code check-ins) to avoid what this warning seems to be advising. It would be one thing if it was a single warning, but it's r-e-l-e-n-t-l-e-s-s. This needs to be reverted.

[samtgarson]

Would maintainers be open to a configuration option which disables these relentless logs?

[trymbill]

Seeing how the warnings are printed based on the existence of the keys (see: https://github.com/expo/sentry-expo/blob/master/plugin/src/withSentry.ts#L63), but the actual value that's used (app.json vs environment variables) is based on whether or not config.authToken is truthy (see: https://github.com/expo/sentry-expo/blob/master/src/hooks/upload-sourcemaps.ts#L69), it seems that setting "authToken": false silences the warning and forces Sentry to look for the environment variable.

"hooks": {
  "postPublish": [
    {
      "file": "sentry-expo/upload-sourcemaps",
      "config": {
        "organization": "my-org",
        "project": "my-project",
        "authToken": false
      }
    }
  ]
}

[zowebs]

I solved it by setting "authToken": false in app.json and then adding .sentryclirc file to the root of the project with the following code:

[auth]
token=YOURAUTHTOKEN

dont forget to include this file in .gitignore

[SleeplessByte]

Thanks @trymbill. That seems like a good workaround.

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[SleeplessByte]

It's definitely not stale, but the workaround... works. May have been fixed since ...

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[SleeplessByte]

You know what would be great? If stale bot was turned off.

[kbrandwijk]

@SleeplessByte Does the issue still exist? If so, feel free to say so. If not, it's pointless to comment just to keep the bot away, in which case I'm happy to close the issue manually.

[SleeplessByte]

Yes it still exists. Just like the other issues I've kept alive for months if not years, and spend time on reporting or investigating in order to be helpful. Some weeks i get over 25 emails from issues i have open here just because stalebot has decided my time isnt worth that much.

It's absolutely hostile to make me "keep an issue alive" by making me recheck every 60 days if things are still broken. If no work has been done in the area, issues don't magically resolve.

I'm always happy to try to provide more information or dig deeper when asked, but closing issues just because they're "old" or "stale" doesn't help the project. It adds a lot of unnecessary noise to issues and honestly it makes me less and less inclined to report them in the first place.

[michalstrzelecki]

Yes, it still exists.

[kbrandwijk]

Yes it still exists. Just like the other issues I've kept alive for months if not years, and spend time on reporting or investigating in order to be helpful. Some weeks i get over 25 emails from issues i have open here just because stalebot has decided my time isnt worth that much.

It's absolutely hostile to make me "keep an issue alive" by making me recheck every 60 days if things are still broken. If no work has been done in the area, issues don't magically resolve.

I'm always happy to try to provide more information or dig deeper when asked, but closing issues just because they're "old" or "stale" doesn't help the project. It adds a lot of unnecessary noise to issues and honestly it makes me less and less inclined to report them in the first place.

I the issue still exists, then provide something actionable, like a minimum viable reproduction repo. If I initialize a new SDK 47 project with npx create-expo-app and run it, I don't see this behavior.

There's nothing hostile about a bot closing stale issues, they got stale for a reason, because there's no actionable information in them at some point.

[SleeplessByte]

Okay.

There's nothing hostile about a bot closing stale issues, they got stale for a reason, because there's no actionable information in them at some point.

The majority of issues on expo that I report that get stale are stale because no one wants to look at it. I've offered multiple times to fix things myself, but the repository is over 2 GBs to clone, and doesn't work well on Windows.

Whilst I appreciate the work that maintainers provide, as a maintainer of multiple OSS projects, this is absolutely lazy and hostile behaviour. The message "you didn't provide something actionable" where in fact it's "no one from the expo team has looked at this since May 23" is why I have no interest in keeping this open, or spending more time on this.

If it's indeed resolved, then yay, me closing this is better for everyone :)

[bradjones1]

I'd chime in here and try to defuse some of the hot rhetoric that closed out this ticket. I agree in general with the frustrating DX of repositories with auto-close bots. I also respect the maintainers of big OSS projects to implement something like that to keep the issue queues from getting unwieldy.

I came to this issue, probably like all the rest of you, because I was tiring of seeing the log spam. Fair enough. The "fix" of providing a false value is a good-enough shim, and sure, it would be nice to not have to do that.

@kbrandwijk's request for an MVP reproduction isn't unreasonable. I think the psychology of many of us who run into these kinds of issues is, it's not that frustrating as to motivate us to spend the time to make the reproduction. And hence, the issue stays open and stale.

I think there's some value in keeping issues like this open because they'll be "in the backlog," as it were, and not lost. But I don't think it helps anyone to get angry or frustrated.

Anyway, just providing some extra context and hopefully we can all try to communicate better in issue queues like this.

[SleeplessByte]

@bradjones1 I provided an MVP reproduction with the steps in the first issue. It's the steps I followed when creating the issue, after doing the research that it wasn't on me.

The problem isn't with this particular request but with the majority of issues that are reported are auto-closed, as if that somehow magically resolves them. I've seen numerous of people provide MVPs, snacks, GitHub projects, and/or detailed instructions, as did I in this issue, and as did I in many many other issues in expo-owned repos.

Out of this list (and there's more), 2 were picked up and fixed, 2 are still open, 1 was solved as a side-effect and everything else is still a problem.

As a maintainer of various big OSS repositories, and as someone who always does research before opening an issue in other's, this isn't an isolated incident, and it absolutely doesn't defuse anything as far as I am concerned. I'm a happy, paying customer with 7 organizations (read: separate plans), and I think the technology is amazing, which is why I wanted to contribute.

That said, to reiterate, with this hostile behaviour on the OSS side, I have no interest in spending my free time here. Take that at face value. I unsubscribed from this issue (now, right after posting this) so if you happen to respond again, I probably won't see it, unless you tell me on Twitter.

[SleeplessByte]

@brentvatne as promised https://github.com/XPBytes/issue-sentry-expo