Blog posts uploaded as daily logs in supervisor dashboard for team_id 338

[linberg]

In the supervisor dashboard (id: 1306) for team_id 338, blog posts from other teams have been uploaded as daily logs on 7 occasions (11.08., 15.08., 04.09., 06.09., 08.09., 09.09. and 11.09.) always at 02:00 CEST. Please see screenshot.

EDIT (Maud) In the screenshot, only the posts with the photo avatar are really by team id 338, the other posts are feed entries from other teams.

[emcoding]

Thanks for reporting this @linberg. I'll look into it.

[emcoding]

The supervisor dashboard redirects to the activity page to show the status updates of the team.
The problem occurs with the activity page.

It looks like there are two problems here.

1. The feed entries are trying to load pictures on AWS S3 and don't get access.
   

2. Team id 338 is the only team where the activities try to get access to other teams' feed entries 🤔
   

I did not figure out yet what the source of the problem(s) are. Tips that gives me a direction are welcome!
( @carpodaster , @klappradla )

[emcoding]

@linberg Do you recall if this problem existed before last week? Or did the post from Sept 8 and Sept 9 appear at once this week?

[linberg]

First time this issue occurred was with the first blog post, so August 11th. There was another bug with this team as well during the application process, their application had showed up under their last year's team name (as they had also applied then). Also at the beginning of the program their daily logs were also going under their last year's team name, I unfortunately don't know the ID, but I think @mkalininait had looked into that issue.

[klappradla]

I don't have time to look into this right now @F3PiX, but the S3 issue may have something to do with me updating the gem...? It's the only touchpoint recent commits had with S3 as far as I remember.
I can just revert the commit and see if we're back at normal with this.

[emcoding]

Thanks, @klappradla, I thought of that but Linda reports that it occurred long before the gem update. Let me look into it to see if I find something else first. Thanks a lot!

[klappradla]

Fine. I by the time read the migration guide for updating the gem from v2 to v3, having only the dedicated library gems instead of the whole package, etc. and it all seemed to be straight forward (as in no changes in the code required).

Still, if it's likely to be the cause of the issue:

git revert 36d357bd11fc84f7525e9d5b0179934812e58a8d

I can then later on look into the details of updating the gem.

[emcoding]

@klappradla I can't find any trace of AWS libraries in my External Libraries folder. So yes, I think there is a problem. I am going to revert the commit. 👾

[emcoding]

@klappradla After reverting the aws gem, the same access errors occur.
Could it be that the credentials need to be updated after gem changes?

[klappradla]

I haven't seen anything pointing in that direction @F3PiX. The upgrade guide for v3 does not have anything regarding credentials in it. And the guide for upgrading within the v2 versions has some bits around credentials, but nothing should be "current" enough for having caused our problem I think.

[emcoding]

Okay, Thanks!!!! So, it seems highly unlikely that is has to do with AWS api. Must be something in the team, then. I'll try something else.

[carpodaster]

I totally overlooked it. The AWS 403s might be related, but I'm closing this in favor of the more recent #901 and will create a new issue to investigate the possible AWS bug.