1397857 - /report/index page in webapp is broken in local dev environment

Status: RESOLVED FIXED

(Socorro :: General, task)

Description

[Will Kahn-Greene [:willkg] ET needinfo? me]

When running the local development environment, one can process a bunch of crashes and the processed crashes get saved in the local S3 container, postgres, and Elasticsearch. Other parts of the site show these crashes.

However, if you go to the report/index/ page for a specific crash you processed, the webapp shows the "Crash Not Found" page.

The current theory is that the webapp isn't configured correctly to look at the local S3 container.

This bug covers figuring out the problem and fixing it.

Comment 1

[Will Kahn-Greene [:willkg] ET needinfo? me]

This is a pretty critical part of the webapp especially when testing things locally.

Grabbing it to look into today.

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

Attachment: pr 3966 - fix /report/index in webapp

Comment 3

[[github robot]]

Commit pushed to master at https://github.com/mozilla-services/socorro

https://github.com/mozilla-services/socorro/commit/4f008f869ca8dcf19c3af9631c7bbb03234dc715
fixes bug 1397857 - configure webapp s3 bits (#3966)

The local dev environment requires that we use a different boto connection
context and that requires a bunch of additional configuration. This adjusts the
webapp configuration to carry all that through.

The defaults are taken from the configuration of the appropriate classes.

Comment 4

[Will Kahn-Greene [:willkg] ET needinfo? me]

Peter pointed out that it's entirely possible to still get the "Crash not found" page, but the problem stems from localstack-s3 not persisting well.

I created bug #1398157 to cover that.

Comment 5

[[github robot]]

Commit pushed to master at https://github.com/mozilla-services/socorro

https://github.com/mozilla-services/socorro/commit/0eb61ec63535cb163b21365cb731b401f967ecd7
fixes bug 1397857 - fix calling format (#3972)

For boto connections, we use RegionalS3ConnectionContext and subclasses. This
family of connection contexts default to OrdinaryCallingFormat rather than
SubdomainCallingFormat. This is important because we have periods in our bucket
names and thus SubdomainCallingFormat doesn't work.

However, when I picked the default for resource.boto.calling_format in the
original commit, I looked at S3ConnectionContext rather than
RegionalS3ConnectionContext and thus used the wrong one and now everything is
hosed in -stage and Sentry is giving me dirty looks late on a Friday just before
the weekend.

This fixes all of that.

Comment 6

[Will Kahn-Greene [:willkg] ET needinfo? me]

I checked -stage and verified that this is fixed now.