amplify env checkout Hangs

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

How did you install the Amplify CLI?
npm -g i @aws-amplify/cli
If applicable, what version of Node.js are you using?
18.7.0
Amplify CLI Version
9.2.1
What operating system are you using?
macOS 12.5.1
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No.
Amplify Categories
auth, storage, function, api, analytics, hosting, notifications
Amplify Commands
env
Describe the bug
We had previously (a few days ago) deployed Hosting to our dev environment. Everything was working great.
Today, we went to deploy Hosting to our production environment. Coincidentally (before we did anything), we happened to notice that the Amplify Hosting environment build had failed 3 minutes before. This was surprising since 7 minutes prior to that, the build worked (and nothing in the Amplify-deployed Next.js code had changed). Upon further inspection, here's the difference in the Backend Build process:
Successful Build
                                 ## Checking for associated backend environment...
                                 ## Backend environment association found
2022-08-30T18:45:58.137Z [INFO]: ## Running amplify pull to generate aws-exports.js file for frontend
2022-08-30T18:46:00.214Z [INFO]: Amplify AppID found: XXXX. Amplify App name is: XXX
2022-08-30T18:46:00.313Z [INFO]: Backend environment dev found in Amplify Console app: XXX
2022-08-30T18:46:01.408Z [WARNING]: - Fetching updates to backend environment: dev from the cloud.
2022-08-30T18:46:02.663Z [INFO]: Overrides functionality is not implemented for this category
                                 Overrides functionality is not implemented for this category
2022-08-30T18:46:02.663Z [INFO]: Overrides functionality is not implemented for this category
2022-08-30T18:46:02.663Z [WARNING]: - Building resource auth/XXX
2022-08-30T18:46:02.879Z [WARNING]: - Building resource auth/userPoolGroups
2022-08-30T18:46:03.027Z [WARNING]: - Building resource api/XXX
2022-08-30T18:46:03.028Z [WARNING]: - Building resource storage/XXX
2022-08-30T18:46:03.028Z [INFO]: Overrides functionality is not implemented for this category
2022-08-30T18:46:03.029Z [INFO]: Overrides functionality is not implemented for this category
                                 Overrides functionality is not implemented for this category
2022-08-30T18:46:03.029Z [WARNING]: ✔ Successfully pulled backend environment dev from the cloud.
2022-08-30T18:46:03.039Z [WARNING]: - Retrieving channel information for APNS.
2022-08-30T18:46:03.117Z [WARNING]: ✔ Channel is not setup for APNS
2022-08-30T18:46:03.117Z [WARNING]: - Retrieving channel information for FCM.
2022-08-30T18:46:03.223Z [WARNING]: ✔ Channel is not setup for FCM
2022-08-30T18:46:03.223Z [WARNING]: - Retrieving channel information for Email.
2022-08-30T18:46:03.306Z [WARNING]: ✔ Channel is not setup for Email
2022-08-30T18:46:03.306Z [WARNING]: - Retrieving channel information for SMS.
2022-08-30T18:46:03.362Z [WARNING]: ✔ Channel is not setup for SMS
2022-08-30T18:46:03.657Z [INFO]: ✅
2022-08-30T18:46:04.314Z [WARNING]: - Uploading files...

Failed Build
This happened 7 minutes later, without any changes to Amplify:
                                 ## Checking for associated backend environment...
                                 ## Backend environment association found
2022-08-30T19:47:29.419Z [INFO]: ## Running amplify pull to generate aws-exports.js file for frontend
2022-08-30T19:47:31.488Z [INFO]: Amplify AppID found: XXX. Amplify App name is: XXX
2022-08-30T19:47:31.567Z [INFO]: Backend environment dev found in Amplify Console app: XXX

That's the extent of the Backend Build log, so something obviously stopped working.
We then went back to the CLI on a local developer machine and tried to run an amplify env checkout dev. This process now hangs indefinitely (whereas before we could easily switch between environments in about 10-15 seconds):
$ amplify env checkout dev
⠇ Initializing your environment: dev

The same thing happens for an amplify pull:
$ amplify pull --appId XXX --envName dev
⠧ Fetching updates to backend environment: dev from the cloud.

Expected behavior
Amplify Backend Build should successfully check out the dev environment config and place the aws-exports.js as appropriate.
Further, amplify env checkout dev and amplify pull --appId XXX --envName dev should complete successfully in a reasonable amount of time (< 15s).
Reproduction steps

amplify env checkout dev
OR
amplify pull --appId XXX --envName dev
OR
Trigger a dev build on Amplify console.

GraphQL schema(s)
N/A
Project Identifier
4e21dc38ea308f3725f90a3dbaf649db
Log output
N/A
Additional information
We are using a monorepo with the following structure:
/amplify
/app (for a React Native app)
/web (for the Amplify-hosted environment - Next.js)
The only other part to add here is that we did an amplify push with our production environment after this issue occurred. The only change for production was to add Hosting. That all worked correctly. The production hosting is working perfectly, but the dev environment remains broken, as described above.
It's also worth noting that we are using Amplify CLI 9.1.0 for Amplify builds on the console in order to work around the "Creating a nested amplify project is not supported." issue (which is currently broken on 9.2.1):
https://github.com/aws-amplify/amplify-cli/issues/10832#issuecomment-1225879252
https://github.com/aws-amplify/amplify-hosting/issues/2908

Since we are using Amplify CLI 9.1.0 for Amplify frontend builds in the console, I tried switching to the 9.1.0 CLI locally, and it has the same hanging issue, so it doesn't seem to matter if we use 9.1.0 or 9.2.1: the environment checkout doesn't ever finish (even after waiting hours of the command running).

Hey @brianlenz :wave: thanks for raising this! To better understand the context of the issue we have a few follow-up questions:

would you mind posting the latest logs from ~/.amplify/logs?
are there nested amplify/ directories in either/both of the monorepo apps? (/app/amplify?)
are you able to pull this project into a fresh directory?

@josefaidt, thanks for the response! My follow-ups:

The log is 2.2MB and contains project-specific info we'd prefer not to post publicly. Is there some way to share it privately?
No, there aren't any nested amplify directories. The amplify directory lives in the monorepo root, and it's the only one that exists.
It doesn't look like it:

$ amplify pull --appId XXX --envName dev
? Select the authentication method you want to use: AWS profile

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html

? Please choose the profile you want to use default
Amplify AppID found: XXX. Amplify App name is: YYY
Backend environment dev found in Amplify Console app: YYY
$ amplify status
Name: NotInitializedError : Message:
      No Amplify backend project files detected within this folder. Either initialize a new Amplify project or pull an existing project.
      - "amplify init" to initialize a new Amplify project
      - "amplify pull <app-id>" to pull your existing Amplify project. Find the <app-id> in the AWS Console or Amplify Admin UI.

It works when I do the pull into a fresh directory for our production environment, though.

@josefaidt, I don't know if this is related, but we noticed today that when we view the details of a backend environment in the Amplify console, the page "crashes" and disappears. Starting here:

If we click on dev or View details, it opens the details page:

A few seconds (3-10) after the page has loaded, the contents of the page entirely disappear and it's broken:

This issue happens both for the dev environment and the production environment, which is interesting.
Just thought I would mention it since we noticed it, in case it is in any way related to the underlying issue.

@josefaidt, FYI, I successfully created a new staging environment yesterday. It's up and running without issue, as production continues to be. For whatever reason, the dev environment remains broken when attempting to checkout with the CLI. The dev environment itself is functioning just fine (and all of our apps run successfully against it), so the issue appears to be purely with the management of the environment with the Amplify CLI.
It would be great if we had a way to get it fixed and working again. I also think it would be good for the Amplify ecosystem to get the underlying issue fixed so that other users don't run into it. I have a fairly high level of confidence that there's nothing we did that could have broken things. We've been using standard Amplify CLI commands with very little custom behavior in the AWS console, and at the time that it broke, we weren't even making any changes to the environment.
If there's anything I can help with to further the process, let me know! I'd be happy to privately share the Amplify CLI log with you (from the day that things went haywire), as well.
Thanks much!

Hey @brianlenz apologies for the delay but I'm glad to hear the new environment created successfully. Given you were able to create a new environment, can you verify the integrity of the #current-cloud-backend folder after pulling into a fresh directory and the amplify/backend/amplify-meta.json file?

The log is 2.2MB and contains project-specific info we'd prefer not to post publicly. Is there some way to share it privately?

You can try emailing them to<EMAIL_ADDRESS>

Are there any errors in the browser console when the screen goes blank?

Thanks, @josefaidt, and no worries on the delay 👍
I can successfully pull production and staging into an empty directory. Everything looks good for both of those in #current-cloud-backend and amplify/backend/amplify-meta.json. I can switch between them with amplify env checkout and I can do amplify pull, and everything appears to work great.
As soon as I attempt to pull the dev environment, everything goes haywire, and the amplify directories get messed up. When I attempt to pull dev, the pull fails (as shown above). At that point, the #current-cloud-backend directory is empty, as is amplify/backend. So, simply checking out dev seems to break it all.
 I suspect you've hit the heart of the issue. It looks like that file is corrupted. Do you have any ideas how to fix this?
$ unzip \#current-cloud-backend.zip
Archive:  #current-cloud-backend.zip
  inflating: cli.json
  inflating: amplify-meta.json
  error:  invalid compressed data to inflate
file #3:  bad zipfile offset (local header sig):  3096
file #4:  bad zipfile offset (local header sig):  3136
file #5:  bad zipfile offset (local header sig):  3181
file #6:  bad zipfile offset (local header sig):  3231
file #7:  bad zipfile offset (local header sig):  6447
file #8:  bad zipfile offset (local header sig):  6774
file #9:  bad zipfile offset (local header sig):  6829
file #10:  bad zipfile offset (local header sig):  9739
file #11:  bad zipfile offset (local header sig):  10109
file #12:  bad zipfile offset (local header sig):  10143
file #13:  bad zipfile offset (local header sig):  10206
file #14:  bad zipfile offset (local header sig):  10245
file #15:  bad zipfile offset (local header sig):  10634
file #16:  bad zipfile offset (local header sig):  10886
file #17:  bad zipfile offset (local header sig):  10941
file #18:  bad zipfile offset (local header sig):  11225
file #19:  bad zipfile offset (local header sig):  11937
file #20:  bad zipfile offset (local header sig):  12227
file #21:  bad zipfile offset (local header sig):  12942
file #22:  bad zipfile offset (local header sig):  14265
api/ttw3/build/resolvers/Mutation.createJournalMigration.req.vtl:  mismatching "local" filename (api/ttw3/build/resolvers/Mutation.createAudioGuide.res.vtl),
         continuing with "central" filename version
  inflating: api/ttw3/build/resolvers/Mutation.createJournalMigration.req.vtl   bad CRC 92a14e9a  (should be b9a63b49)
file #24:  bad zipfile offset (local header sig):  14681
file #25:  bad zipfile offset (local header sig):  14823
file #26:  bad zipfile offset (local header sig):  16136
file #27:  bad zipfile offset (local header sig):  16306
file #28:  bad zipfile offset (local header sig):  17623
file #29:  bad zipfile offset (local header sig):  17796
file #30:  bad zipfile offset (local header sig):  19365
file #31:  bad zipfile offset (local header sig):  19535
file #32:  bad zipfile offset (local header sig):  21123
file #33:  bad zipfile offset (local header sig):  21307
file #34:  bad zipfile offset (local header sig):  22893
file #35:  bad zipfile offset (local header sig):  23076
file #36:  bad zipfile offset (local header sig):  24620
file #37:  bad zipfile offset (local header sig):  24799
file #38:  bad zipfile offset (local header sig):  26367
file #39:  bad zipfile offset (local header sig):  26541
file #40:  bad zipfile offset (local header sig):  28175
api/ttw3/build/resolvers/Mutation.deletePlan.req.vtl:  mismatching "local" filename (api/ttw3/build/resolvers/Mutation.deleteAudioGuide.res.vtl),
         continuing with "central" filename version
  inflating: api/ttw3/build/resolvers/Mutation.deletePlan.req.vtl   bad CRC 92a14e9a  (should be 8ad980b3)
file #42:  bad zipfile offset (local header sig):  29979
file #43:  bad zipfile offset (local header sig):  30149
file #44:  bad zipfile offset (local header sig):  31780
file #45:  bad zipfile offset (local header sig):  31953
file #46:  bad zipfile offset (local header sig):  33749
file #47:  bad zipfile offset (local header sig):  33919
file #48:  bad zipfile offset (local header sig):  35745
file #49:  bad zipfile offset (local header sig):  35807
file #50:  bad zipfile offset (local header sig):  35991
file #51:  bad zipfile offset (local header sig):  37464
file #52:  bad zipfile offset (local header sig):  39289
file #53:  bad zipfile offset (local header sig):  45826
file #54:  bad zipfile offset (local header sig):  46077
file #55:  bad zipfile offset (local header sig):  46260
file #56:  bad zipfile offset (local header sig):  46316
file #57:  bad zipfile offset (local header sig):  47550
file #58:  bad zipfile offset (local header sig):  49340
file #59:  bad zipfile offset (local header sig):  49501
file #60:  bad zipfile offset (local header sig):  49547
file #61:  bad zipfile offset (local header sig):  49726
file #62:  bad zipfile offset (local header sig):  52081
file #63:  bad zipfile offset (local header sig):  52739
file #64:  bad zipfile offset (local header sig):  54547
file #65:  bad zipfile offset (local header sig):  54673
file #66:  bad zipfile offset (local header sig):  54847
file #67:  bad zipfile offset (local header sig):  54882
file #68:  bad zipfile offset (local header sig):  57220
file #69:  bad zipfile offset (local header sig):  57276
file #70:  bad zipfile offset (local header sig):  57452
file #71:  bad zipfile offset (local header sig):  59760
file #72:  bad zipfile offset (local header sig):  61296
file #73:  bad zipfile offset (local header sig):  61466
file #74:  bad zipfile offset (local header sig):  61516
file #75:  bad zipfile offset (local header sig):  63815
file #76:  bad zipfile offset (local header sig):  63982
file #77:  bad zipfile offset (local header sig):  64155
file #78:  bad zipfile offset (local header sig):  64203
file #79:  bad zipfile offset (local header sig):  66648
file #80:  bad zipfile offset (local header sig):  66702
file #81:  bad zipfile offset (local header sig):  66872
file #82:  bad zipfile offset (local header sig):  66936
file #83:  bad zipfile offset (local header sig):  69407
file #84:  bad zipfile offset (local header sig):  69481
file #85:  bad zipfile offset (local header sig):  69665
file #86:  bad zipfile offset (local header sig):  72599
file #87:  bad zipfile offset (local header sig):  75068
file #88:  bad zipfile offset (local header sig):  75126
file #89:  bad zipfile offset (local header sig):  75309
file #90:  bad zipfile offset (local header sig):  75372
file #91:  bad zipfile offset (local header sig):  77826
file #92:  bad zipfile offset (local header sig):  77895
file #93:  bad zipfile offset (local header sig):  78074
file #94:  bad zipfile offset (local header sig):  81314
file #95:  bad zipfile offset (local header sig):  83767
file #96:  bad zipfile offset (local header sig):  83826
file #97:  bad zipfile offset (local header sig):  84000
file #98:  bad zipfile offset (local header sig):  84080
file #99:  bad zipfile offset (local header sig):  84906
file #100:  bad zipfile offset (local header sig):  84992
file #101:  bad zipfile offset (local header sig):  85774
file #102:  bad zipfile offset (local header sig):  92335
file #103:  bad zipfile offset (local header sig):  92618
file #104:  bad zipfile offset (local header sig):  95712
file #105:  bad zipfile offset (local header sig):  96421
api/ttw3/build/resolvers/Query.getAudioGuide.req.vtl:  mismatching "local" filename (api/ttw3/build/resolvers/Subscription.onUpdatePlan.res.vtl),
         continuing with "central" filename version
  inflating: api/ttw3/build/resolvers/Query.getAudioGuide.req.vtl
  error:  invalid compressed data to inflate
file #107:  bad zipfile offset (local header sig):  96737
file #108:  bad zipfile offset (local header sig):  96817
file #109:  bad zipfile offset (local header sig):  97533
file #110:  bad zipfile offset (local header sig):  99912
file #111:  bad zipfile offset (local header sig):  100146
file #112:  bad zipfile offset (local header sig):  100218
file #113:  bad zipfile offset (local header sig):  100354
file #114:  bad zipfile offset (local header sig):  100432
file #115:  bad zipfile offset (local header sig):  100668
file #116:  bad zipfile offset (local header sig):  106129
file #117:  bad zipfile offset (local header sig):  106839
file #118:  bad zipfile offset (local header sig):  111199
file #119:  bad zipfile offset (local header sig):  111438
file #120:  bad zipfile offset (local header sig):  111501
file #121:  bad zipfile offset (local header sig):  112214
file #122:  bad zipfile offset (local header sig):  112290
file #123:  bad zipfile offset (local header sig):  112526
file #124:  bad zipfile offset (local header sig):  114295
file #125:  bad zipfile offset (local header sig):  115164
file #126:  bad zipfile offset (local header sig):  115266
file #127:  bad zipfile offset (local header sig):  115516
file #128:  bad zipfile offset (local header sig):  117777
file #129:  bad zipfile offset (local header sig):  118678
file #130:  bad zipfile offset (local header sig):  118778
file #131:  bad zipfile offset (local header sig):  119027
file #132:  bad zipfile offset (local header sig):  120508
file #133:  bad zipfile offset (local header sig):  121407
file #134:  bad zipfile offset (local header sig):  121500
file #135:  bad zipfile offset (local header sig):  121745
file #136:  bad zipfile offset (local header sig):  123244
file #137:  bad zipfile offset (local header sig):  124112
file #138:  bad zipfile offset (local header sig):  124189
file #139:  bad zipfile offset (local header sig):  124429
file #140:  bad zipfile offset (local header sig):  126525
file #141:  bad zipfile offset (local header sig):  127409
file #142:  bad zipfile offset (local header sig):  132846
file #143:  bad zipfile offset (local header sig):  133318
file #144:  bad zipfile offset (local header sig):  133380
file #145:  bad zipfile offset (local header sig):  134149
file #146:  bad zipfile offset (local header sig):  134222
file #147:  bad zipfile offset (local header sig):  134688
file #148:  bad zipfile offset (local header sig):  136768
file #149:  bad zipfile offset (local header sig):  137531
file #150:  bad zipfile offset (local header sig):  141697
file #151:  bad zipfile offset (local header sig):  142166
file #152:  bad zipfile offset (local header sig):  143141
file #153:  bad zipfile offset (local header sig):  143907
file #154:  bad zipfile offset (local header sig):  143946
file #155:  bad zipfile offset (local header sig):  144426
file #156:  bad zipfile offset (local header sig):  144478
file #157:  bad zipfile offset (local header sig):  145450
file #158:  bad zipfile offset (local header sig):  145651
file #159:  bad zipfile offset (local header sig):  146130
file #160:  bad zipfile offset (local header sig):  146352
file #161:  bad zipfile offset (local header sig):  147323
file #162:  bad zipfile offset (local header sig):  147379
file #163:  bad zipfile offset (local header sig):  147854
file #164:  bad zipfile offset (local header sig):  148129
file #165:  bad zipfile offset (local header sig):  149066
file #166:  bad zipfile offset (local header sig):  149128
file #167:  bad zipfile offset (local header sig):  149598
file #168:  bad zipfile offset (local header sig):  149669
file #169:  bad zipfile offset (local header sig):  150624
file #170:  bad zipfile offset (local header sig):  1577708
file #171:  bad zipfile offset (local header sig):  1578174
file #172:  bad zipfile offset (local header sig):  1578335
file #173:  bad zipfile offset (local header sig):  1579273
file #174:  bad zipfile offset (local header sig):  1579394
file #175:  bad zipfile offset (local header sig):  1579552
file #176:  bad zipfile offset (local header sig):  1592334
file #177:  bad zipfile offset (local header sig):  1592996
file #178:  bad zipfile offset (local header sig):  1593310
file #179:  bad zipfile offset (local header sig):  1593462
file #180:  bad zipfile offset (local header sig):  1615330
file #181:  bad zipfile offset (local header sig):  1615986
file #182:  bad zipfile offset (local header sig):  1617731
file #183:  bad zipfile offset (local header sig):  1617886
file #184:  bad zipfile offset (local header sig):  1617962
file #185:  bad zipfile offset (local header sig):  1618621
file #186:  bad zipfile offset (local header sig):  1618846
file #187:  bad zipfile offset (local header sig):  1618998
file #188:  bad zipfile offset (local header sig):  1619391
file #189:  bad zipfile offset (local header sig):  1620198
file #190:  bad zipfile offset (local header sig):  1620385
file #191:  bad zipfile offset (local header sig):  1620551
file #192:  bad zipfile offset (local header sig):  1620631
file #193:  bad zipfile offset (local header sig):  1620769
file #194:  bad zipfile offset (local header sig):  1621068
file #195:  bad zipfile offset (local header sig):  1621233
file #196:  bad zipfile offset (local header sig):  1621319
file #197:  bad zipfile offset (local header sig):  1621456
file #198:  bad zipfile offset (local header sig):  1621551
file #199:  bad zipfile offset (local header sig):  1621712
file #200:  bad zipfile offset (local header sig):  3048820
file #201:  bad zipfile offset (local header sig):  3049617
file #202:  bad zipfile offset (local header sig):  3049802
file #203:  bad zipfile offset (local header sig):  3049958
file #204:  bad zipfile offset (local header sig):  3050763
file #205:  bad zipfile offset (local header sig):  3050891
file #206:  bad zipfile offset (local header sig):  3051074
file #207:  bad zipfile offset (local header sig):  3051232
file #208:  bad zipfile offset (local header sig):  3051673
file #209:  bad zipfile offset (local header sig):  3052335
file #210:  bad zipfile offset (local header sig):  3052647
file #211:  bad zipfile offset (local header sig):  3052799
file #212:  bad zipfile offset (local header sig):  3065635
file #213:  bad zipfile offset (local header sig):  3066291
file #214:  bad zipfile offset (local header sig):  3067748
file #215:  bad zipfile offset (local header sig):  3067903
file #216:  bad zipfile offset (local header sig):  3067972
file #217:  bad zipfile offset (local header sig):  3068631
file #218:  bad zipfile offset (local header sig):  3068848
file #219:  bad zipfile offset (local header sig):  3069000
file #220:  bad zipfile offset (local header sig):  3069147
file #221:  bad zipfile offset (local header sig):  3069954
file #222:  bad zipfile offset (local header sig):  3070343
file #223:  bad zipfile offset (local header sig):  3070509
file #224:  bad zipfile offset (local header sig):  3070676
file #225:  bad zipfile offset (local header sig):  3070814
file #226:  bad zipfile offset (local header sig):  3070887
file #227:  bad zipfile offset (local header sig):  3071052
file #228:  bad zipfile offset (local header sig):  3071344
file #229:  bad zipfile offset (local header sig):  3071481
file #230:  bad zipfile offset (local header sig):  3071560
file #231:  bad zipfile offset (local header sig):  3071721
file #232:  bad zipfile offset (local header sig):  3071809
file #233:  bad zipfile offset (local header sig):  3072606
file #234:  bad zipfile offset (local header sig):  4499707
file #235:  bad zipfile offset (local header sig):  4499863
file #236:  bad zipfile offset (local header sig):  4500041
file #237:  bad zipfile offset (local header sig):  4500169
file #238:  bad zipfile offset (local header sig):  4501353
file #239:  bad zipfile offset (local header sig):  4501511
file #240:  bad zipfile offset (local header sig):  4501698
file #241:  bad zipfile offset (local header sig):  4502360
file #242:  bad zipfile offset (local header sig):  4503031
file #243:  bad zipfile offset (local header sig):  4503183
file #244:  bad zipfile offset (local header sig):  4503509
file #245:  bad zipfile offset (local header sig):  4504165
file #246:  bad zipfile offset (local header sig):  4516997
file #247:  bad zipfile offset (local header sig):  4517152
file #248:  bad zipfile offset (local header sig):  4518627
file #249:  bad zipfile offset (local header sig):  4519286
file #250:  bad zipfile offset (local header sig):  4519324
file #251:  bad zipfile offset (local header sig):  4519476
file #252:  bad zipfile offset (local header sig):  4519529
file #253:  bad zipfile offset (local header sig):  4520336
file #254:  bad zipfile offset (local header sig):  4520374
file #255:  bad zipfile offset (local header sig):  4520540
file #256:  bad zipfile offset (local header sig):  4520589
file #257:  bad zipfile offset (local header sig):  4520727
file #258:  bad zipfile offset (local header sig):  4521186
file #259:  bad zipfile offset (local header sig):  4521351
file #260:  bad zipfile offset (local header sig):  4523335
file #261:  bad zipfile offset (local header sig):  4523472
file #262:  bad zipfile offset (local header sig):  4523633
file #263:  bad zipfile offset (local header sig):  4524430
file #264:  bad zipfile offset (local header sig):  4524586
file #265:  bad zipfile offset (local header sig):  4524714
file #266:  bad zipfile offset (local header sig):  4525268
file #267:  bad zipfile offset (local header sig):  4526053
file #268:  bad zipfile offset (local header sig):  4526877
file #269:  bad zipfile offset (local header sig):  4527656
file #270:  bad zipfile offset (local header sig):  4528494
file #271:  bad zipfile offset (local header sig):  4529476
file #272:  bad zipfile offset (local header sig):  4530312
file #273:  bad zipfile offset (local header sig):  4531292
file #274:  bad zipfile offset (local header sig):  4531589
file #275:  bad zipfile offset (local header sig):  4532476
file #276:  bad zipfile offset (local header sig):  4533301
file #277:  bad zipfile offset (local header sig):  4534271
file #278:  bad zipfile offset (local header sig):  4534580
file #279:  bad zipfile offset (local header sig):  4535306
file #280:  bad zipfile offset (local header sig):  4535607
file #281:  bad zipfile offset (local header sig):  4536486
file #282:  bad zipfile offset (local header sig):  4536795
file #283:  bad zipfile offset (local header sig):  4537689
file #284:  bad zipfile offset (local header sig):  4537987
file #285:  bad zipfile offset (local header sig):  4538706
file #286:  bad zipfile offset (local header sig):  4539007
file #287:  bad zipfile offset (local header sig):  4539885
file #288:  bad zipfile offset (local header sig):  4540731
file #289:  bad zipfile offset (local header sig):  4541717
file #290:  bad zipfile offset (local header sig):  4542015
file #291:  bad zipfile offset (local header sig):  4542733
file #292:  bad zipfile offset (local header sig):  4543016
file #293:  bad zipfile offset (local header sig):  4543726
file #294:  bad zipfile offset (local header sig):  4544007
file #295:  bad zipfile offset (local header sig):  4544876
file #296:  bad zipfile offset (local header sig):  4548447
file #297:  bad zipfile offset (local header sig):  4548499
file #298:  bad zipfile offset (local header sig):  4552945
file #299:  bad zipfile offset (local header sig):  4556355
file #300:  bad zipfile offset (local header sig):  4557065
file #301:  bad zipfile offset (local header sig):  4559903
file #302:  bad zipfile offset (local header sig):  4564258
file #303:  bad zipfile offset (local header sig):  4568378
file #304:  bad zipfile offset (local header sig):  4572506
  inflating: api/ttw3/build/stacks/UserCompletedPlan.json
  inflating: api/ttw3/build/stacks/UserMigration.json
  inflating: api/ttw3/build/stacks/UserPlan.json

Thanks, @josefaidt! Right now, the dev environment (backend) is not connected to a frontend. The staging and production backends are the two environments currently connected to frontends.
Thanks for your continued support!

@josefaidt I should mention that at one point the dev environment had been connected to a frontend, but we switched things around so that is no longer the case.

@brianlenz had the same case. I added some frontends to my backend app through the amplify console "new app" function.
The CLI V. 7.26 was the last working version, after that, amplify console build was always destroy my #current-cloud-backend zip file. The CLI from my local Mac was fine with v8. I just pulled the aws-export.js and don't build the backend within the frontend deploy. I tested now v10 in the build settings, and it is working.
If you have a git repo, you can restore your #current-cloud-backend zip.
Just zip your amplify/backend as #current-cloud-backend.zip, important is, that you mark the files itself, and not the backend folder. So that there is no parent folder inside the zip. After that, you can upload it to s3 and it should work again.

Hey @biller-aivy thanks for chiming in here with the workaround to restore the current-cloud-backend zip archive, @brianlenz did this work for you?

Hi @josefaidt! I haven't had a chance yet to try this. I need to go back in our git history to (approximately) the day that we had this issue and see if I can restore it from that. One question I have is: what could happen if we create current-cloud-backend from data that doesn't exactly represent what is currently deployed? What could go wrong?
Worst case, I will just manually destroy the environment and all its resources and start over creating a new environment from scratch. It's not ideal, but it's workable for us.
Lastly, I personally feel it would be worth figuring out why the Amplify CLI broke the management of our dev environment at all. We didn't do anything specifically that would have corrupted this zip file (and I'd argue the Amplify CLI should never let such a thing occur), so there must be some kind of bug in Amplify CLI that resulted in this issue, right?

Hey @brianlenz no worries!

what could happen if we create current-cloud-backend from data that doesn't exactly represent what is currently deployed? What could go wrong?

I tried this out with a sample project and it appears to not have disturbed existing resources, and instead is confused about the resource state for some of the newer resources (ones that have not already been pushed)
While in the affected environment:

make a copy of the zip archive in your s3 deployment bucket for good measure
in your project, cd into backend directory cd amplify/backend
zip contents with zip -r "../../#current-cloud-backend.zip" * (this will create the zip archive in your project root)
upload zip contents to your s3 deployment bucket
delete the amplify/#current-cloud-backend directory locally
run amplify init --envName dev --yes to reinitialize the project (this will pull the contents of the recently uploaded zip archive)
run amplify status, observe mismatch in resource states
run amplify push --force to forcefully push resources

Lastly, I personally feel it would be worth figuring out why the Amplify CLI broke the management of our dev environment at all. We didn't do anything specifically that would have corrupted this zip file (and I'd argue the Amplify CLI should never let such a thing occur), so there must be some kind of bug in Amplify CLI that resulted in this issue, right?

Great callout, and yes, there is a known instance we are investigating where using the Amplify Hosting feature to connect new frontend apps to existing backends, the backend is undergoing a push when we pushed frontend changes. This can cause a corrupted current-cloud-backend zip (similar to what @biller-aivy has described)

Super helpful, @josefaidt, thanks! I'll let you know once I have a chance to work on this 👍

Great callout, and yes, there is a known instance we are investigating where using the Amplify Hosting feature to connect new frontend apps to existing backends, the backend is undergoing a push when we pushed frontend changes. This can cause a corrupted current-cloud-backend zip (similar to what @biller-aivy has described)

Sounds perfect 🙌

Hey @brianlenz upon further review I will close this issue in favor of tracking https://github.com/aws-amplify/amplify-cli/issues/11072, which we have recently added to our strategic queue of issues to track cross-team efforts. Please subscribe to the linked issue for further updates

OK, thank you, @josefaidt! Sorry that we never got back around to working on this. Too many other priorities 🤪 I suspect that when we get back to this, we will probably just try to delete the broken environment and start all over from scratch...


Blender hair export

This pull request adds a new Blender-specific hair export method.
Benefits are faster export time and much lower memory usage during export. Also a few new features.
Can you please check the following things:

For the lower memory usage, I need numpy arrays (Python lists use unnecessary doubles instead of floats). So I had to add boost_numpy to the linked libraries in CMakeLists.txt. I changed the Linux build script to make this work - are similar changes required for Windows (and MacOS?).
Also, I could not get the travis build script to work yet, it can't find the boost_numpy library.
I had to increase BOOST_PYTHON_MAX_ARITY from 18 to 22 because the new method needs a lot of parameters. Does this have any detrimental effect?

I have fixed TravisCI and boost_numpy discovery however  boost_numpy is not part of Windows pre-compiled binaries. @acasta69 please, can you update the WindowCompileDeps repository to include boost_numpy ? It is part of standard boost components ?

Boost_python build generates also boost_numpy if numpy is installed... or at least it should.
This is working with the latest version (1.15.1), but it seems that it is incompatible with the older one shipped with Blender 2.79b. At Blender start I get this:
found bundled python: C:\Dati\Various\Personal\Tools\Blender\blender-2.79b-windo ws64\2.79\python RuntimeError: module compiled against API version 0xc but this version of numpy is 0xa ImportError: numpy.core.umath failed to import Exception in module register(): 'C:\\Users\\italcas1\\AppData\\Roaming\\Blender Foundation\\Blender\\2.79\\scripts\\addons\\BlendLuxCore\\__init__.py' ImportError: numpy.core.umath failed to import
Does anything similar happen with Linux? Which numpy version are you using there?
I am trying to build with older versions having the required 0xA API, but for some reason boost does not detect them and the lib is not built.
I'm a bit stuck at the moment, but keeping on trying...

Ok, this seems to be solved now, I've built boost_numpy against numpy v. 1.11.3, that is the closest to the 1.10.1 used by Blender and using the same API level. I hope this is not a problem...
I will submit pull requests later today.

Great, thank you!


Report split

Not very happy with it. I'd rather would have made report accept the relevant child nodes instead of determining this in the report class based on string, but in light of the changes still coming I thought for now it's safer to keep everything in one place.

I'm merging this ahead of review so that we can deploy but feel free to still add comments and then they will be addressed subsequently.


prepare release of v1.1.0

@adrianthedev This PR is ready pending updating the release date in the changelog when it is actually uploaded to rubygems!


[#130991743] Remove application_status from framework users export

Current implementation of application_status check requires N+1 queries to request draft services for each framework supplier. This is timing out due to the number of suppliers in production.
As a temporary workaround, since we're mainly interested in exports for live frameworks at the moment we're removing application status values from the export.

:+1:
Yep let's get this in and worry later about how to do it properly... not sure if making application status a property on supplier_framework will help as it will still require the same amount of database lookups, just wrapped with syntactic sugar.  Another way might be storing and managing a separate count-of-submitted-services field, but feels a bit mad.

If we do want to do that though we'd ideally need to get it in before DOS2 opens, thought could do a migration easily enough later I guess.


Doesn't seem to work with Foobar2000 v2.0

I installed the latest version of Foobar200 v2.0 (stable release 64 bit) on Widows 10
It's not portable installation, so I extracted the content of the profile directory into %AppData%\foobar2000-v2
I opened the program but I wasn't prompted by any message.
This theme is not compatible with v2.0 it seems. Am I right?
And if it is not compatible, Do you have any plans to make it compatible with v2.0?

The answer to your question was already answered here: https://github.com/TT-ReBORN/Georgia-ReBORN/issues/102


required_with_all validation not populating :values in error message

Seems like someone just forgot to add the replaceRequiredWithAll method in Illuminate\Validation\Validator. The :values was not getting populated`
Problem:
The height field is required when :values is present.

Desired result:
The height field is required when field1 / field2 / field3 is present.

Solution:
/**
 * Replace all place-holders for the required_with_all rule.
 *
 * @param  string  $message
 * @param  string  $attribute
 * @param  string  $rule
 * @param  array   $parameters
 * @return string
 */
protected function replaceRequiredWithAll($message, $attribute, $rule, $parameters)
{
    return $this->replaceRequiredWith($message, $attribute, $rule, $parameters);
}

Using Laravel 4.2 btw. Creating a PR for this in a few minutes.

Using Laravel 4.2 btw.

We don't support L4.2 for minor bugs, sorry.

Aww :disappointed: I'll use my fork then and merge all my personal fixes into its master branch, should work too.


build: increase snapshot publish job queue confidence threshold

We recently added a new step to the snapshot publish job. The step will block
the job until all previous snapshot publish jobs that have been launched before
complete.
This step relies on the CircleCI API which does not always refresh immediately.
This means that we could run into a race condition where the queue does not
detect previous jobs. This has been observed with:
https://app.circleci.com/pipelines/github/angular/components/9618/workflows/52fef2b9-8059-4c00-8c2e-347b83ad1031/jobs/158528/steps
We fix this by increasing the confidence threshold of the queue step, so that
it will perform a second CircleCI request after a delay to avoid the race condition
in the most common cases. It's a trade-off between stability and delay. We could
certainly increase the threshold further, but that will slow down CI on publish
branches, so we start experimenting with lower threshold values first.
Overall this queue has been working quite well so far. just two potential race conditions that
should be fixed by this change.

@jelbourn The delay should be of 11 seconds according to the queues orb: https://github.com/eddiewebb/circleci-queue/blob/master/src/commands/until_front_of_line.yml#L166.
I don't know how why this this specific number has been chose, but it should be good for avoiding the race conditions. We could always increase the confidence level if desired.


General requirements for Shenyu gateway

Question
After using the Shenyu gateway, I have an urgent requirement. I would like to know if your official solution can fulfill it. I need to pass the client IP, TraceId, and JWT token obtained at the gateway side to the Dubbo service backend through the Dubbo RPCContext instead of passing them as regular parameters. Thank you.

You can use GeneralContextPlugin to achieve the functionality you want.
In dubboRpc  . This data will be placed in RpcContext


pt-br: O serviço está temporariamente indisponível.

A aba do compilador informa esta mensagem. O problema aconteceu neste momento.
Uso o navegador Chrome sobre o Ubuntu 16.04

Hi!
Of course, I do.
I'm using the portuguese version of the site (docs.microsoft.com/pt-br) and
the online C# compiler isn't running. A short time aftet I click on "Run
code" is shown a message that the service is not avaiable. This is happened
ever.
__________________________________________________________
Francisco Sobrinho  http://lattes.cnpq.br/6916947700958849
Em ter, 7 de ago de 2018 às 12:23, LadyNaggaga<EMAIL_ADDRESS>escreveu:

Desculpe, estou usando o tradutor do Google. Você pode me informar se esse
problema está acontecendo?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/try/issues/134#issuecomment-411095873, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AI6ZohygaJNIqkhxWZ37suyNV_5M4F7_ks5uObDkgaJpZM4VuxaV
.

Obrigado @nephew92   I am going file this a bug and we  will look into it.

This looks like it was a momentary outage. @nephew92 are you still seeing the issue?

Closing issue since we haven't heard back of recent occurrence of the above. @nephew92  please feel to let us know if this happens again.


[$500]  Distance - Start and Finish data does not remain when user change to Manual/Scan

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Issue found when executing PR https://github.com/Expensify/App/pull/26622
Action Performed:

Open New Expensify app
Tap FAB button
Tap Request money
Tap Distance
Enter Start address
Enter Finish address
Navigate to Scan/Manual tab
Turn back to Distance tab

Expected Result:
Entered Start and Finish data should remain when user change to Manual/Scan
Actual Result:
Start and Finish data does not remain when user change to Manual/Scan
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] Windows / Chrome

Version Number: 1.3.63-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/78819774/d979c890-865a-49e9-a372-8b0e6a988c2f
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~013db7c954b21603ab
Upwork Job ID:<PHONE_NUMBER>091473920
Last Price Increase: 2023-09-04

reproduced!

Proposal
Please re-state the problem that we are trying to solve in this issue.
Distance - Start and Finish data does not remain when user change to Manual/Scan
What is the root cause of that problem?
After selecting the location (start and finish) we save it in ONYX in the transcation_{transactionID} field. But when selecting another tab we reset the field
https://github.com/Expensify/App/blob/f67bf9f88c08fe2cebe16202d1244299a9640ea3/src/pages/iou/MoneyRequestSelectorPage.js#L66
It causes that the transactionID field in iou will be empty. Then, when coming back the new transaction will be created
https://github.com/Expensify/App/blob/f67bf9f88c08fe2cebe16202d1244299a9640ea3/src/pages/iou/DistanceRequestPage.js#L48-L53
The old transaction with the old value will not be used anymore
What changes do you think we should make in order to solve the problem?
When selecting another request tab, we should keep transactionID in iou field. So that, the new transaction will be not created by this logic
https://github.com/Expensify/App/blob/f67bf9f88c08fe2cebe16202d1244299a9640ea3/src/pages/iou/DistanceRequestPage.js#L48-L53
To do that, in resetMoneyRequestInfo function we can define transactionID param with the default value is ''.
And in here
https://github.com/Expensify/App/blob/f67bf9f88c08fe2cebe16202d1244299a9640ea3/src/pages/iou/MoneyRequestSelectorPage.js#L66
we pass transactionID to this fucntion
        IOU.resetMoneyRequestInfo(moneyRequestID, lodashGet(props.iou, 'transactionID', ''));

What alternative solutions did you explore? (Optional)

updated proposal: Adding alternative solution

Proposal
Please re-state the problem that we are trying to solve in this issue.
Distance - Start and Finish data does not remain when user change to Manual/Scan
What is the root cause of that problem?
We reset the Request Info in resetMoneyRequestInfo, but did not give the condition to check if the current tab is the same as the new tab or not run & resetMoneyRequestInfo based on that condition
https://github.com/Expensify/App/blob/f67bf9f88c08fe2cebe16202d1244299a9640ea3/src/pages/iou/MoneyRequestSelectorPage.js#L64-L67
What changes do you think we should make in order to solve the problem?
Both the solution of @tienifr and @DylanDylann is similar, but will not satisfy the Expected behavior & we didn't really need to add and track props.iou.
What we should do instead, is handle it simply via condition on resetMoneyRequestInfo & onTabPress

resetMoneyRequestInfo

const resetMoneyRequestInfo = (currentTab) => {
        if (currentTab === CONST.TAB.DISTANCE) {
            return;
        }

        const moneyRequestID = `${iouType}${reportID}`;
        IOU.resetMoneyRequestInfo(moneyRequestID);
};

onTabPress

<TabSelector
          state={state}
           navigation={navigation}
           onTabPress={(newTab) => {
                   if (props.selectedTab !== newTab) {
                           return;
                   }
                   resetMoneyRequestInfo(newTab);
            }
            position={position}
/>

Result
https://github.com/Expensify/App/assets/20473526/97e0a1fd-04d8-4cf6-9887-e9d5ba05776c
cc: @narefyev91 @adelekennedy

@adelekennedy are we sure that we should keep values? We have 3 options to request money - either manually or scan or distance - navigating between tabs - means that user should not expect saving redundant information. Maybe i'm wrong but needs to clarify

I also thought this was expected behavior when I encountered it

I can imagine that the user would benefit from keeping the waypoint value (in case let say they inputted 5 points, and accidently switch from Distance to another tab)
In case on another tab, its make sense to keep the reselt to default behaviour as it's a one item (time) input
Additional note: In my proposal, I've laid out the details on those 2 conditions
@narefyev91 @adelekennedy

~I also thought this was expected behavior when I encountered it~ Actually since the amount persists on the manual tab, the expected behavior might be saving the waypoints

Amount exists only if you not do any interaction on other tabs - for example choosing start/end on distance tab will reset amount of manual. We need to have correct understanding how it should be working @adelekennedy

This is intentional - https://github.com/Expensify/App/issues/26579#issuecomment-1703948897

Let's close - looking back at this I hit external too soon without covering expected behavior


fix(KONFLUX-3663): format PipelineRun files and upload SAST results

This update configures the SAST task to upload SARIF results to quay.io for long-term storage
Please note that this PR was automatically generated and may include unrelated changes due to automatic YAML formatting performed by yq
The YAML files will be indented using 2 spaces, if the YAML file uses indentationless list the automation will try to keep this format
The PR contains two separate commits:

Format YAML files: Ensures consistent indentation and formatting of the YAML files
Upload SAST results: Configures the PipelineRun files to enable uploading SARIF results to quay.io

Separating these changes into two commits simplifies the review process. The first commit focuses on indentation and formatting, while the second commit contains the semantic changes
Related:

https://issues.redhat.com/browse/KONFLUX-3663
https://issues.redhat.com/browse/KONFLUX-2263

/close
the file name is changed from .tekton/managedcluster-import-controller-addon-mce-26-pull-request.yaml to .tekton/managedcluster-import-controller-addon-mce-27-pull-request.yaml


Little change to make it possible to load async or with script loaders

Hi guys, I've tried to load Bugsnag script asynchronously and with script loaders (head.js and $script) and it always informed me that my apiKey was invalid. I've debugged and found this:
https://github.com/bugsnag/bugsnag-js/blob/b70cd8de3c503f6ec6ebc9fc0d415ef50c6a0e28/src/bugsnag.js#L231-L232
This two lines consider that the script will always be the last one on the page, but this will only be true if you're loading it synchronously.
Maybe it should find the script based on "src", matching for "bugsnag". What you guys think? I can send a PR later with a possible solution :]

Another possible solution would be asking for people to add something like:
<script src="" data-bugsnag />

Looking for this data attribute and fallback to the last script on page, when it wasn't found.

I really like the second idea, as the first is just asking for trouble.
Good idea!
On Thu, 19 Nov 2015 at 1:59 AM André Gil<EMAIL_ADDRESS>wrote:

Another possible solution would be asking for people to add something like:

Looking for this data attribute and fallback to the last script on page,
when it wasn't found.

—
Reply to this email directly or view it on GitHub
.

--
Regards,
Jacob Marshall
Email<EMAIL_ADDRESS>Phone: (+64) 21 026 940 83

@gil Thank you for the report! This is definitely a problem which could be solved by making the script detection more robust.

Maybe it should find the script based on "src", matching for "bugsnag".

This could prove brittle with more than one bugsnag script on the page, or otherwise a time consuming search.

Another possible solution would be asking for people to add something like:
<script src="" data-bugsnag />

Looking for this data attribute and fallback to the last script on page, when it wasn't found.

If we take into account that bugsnag-js supports a lot of browsers and versions and data-* attribute support is only universal for the latest versions of browsers, I think that with the fallback it should provide a better experience for users on newer browsers.
We can discuss finer details of the implementation over a PR though! :+1: Thanks!

This sounds like a good idea, but there are a few things to be aware of with loading the current version of Bugsnag.js asynchronously:
In order to get good debugging information for all errors, Bugsnag should be loaded synchronously, but this is only required for "medium-old" browsers (those that fail this check: https://github.com/bugsnag/bugsnag-js/blob/master/src/bugsnag.js#L541, IE 8-10 and Firefox 3-30, safari 7, for older-still browsers there's typically no way at all of getting this information). This is necessary because it's not possible to (in IE/Safari: get a correct stacktrace from those browsers in window.onerror, in Firefox: get a column number in window.onerror which is needed to group exceptions better), so we override addEventListener and friends to add a try-catch block for old browsers.
Thus if your code loads before bugsnag on old browsers, you will miss some error reports because there's not enough information, and get no stack traces for others. (You'll also miss errors that happened before Bugsnag loads, but that's probably fine).
If async loading is important to you (and you care about the old browsers) it would be better to minify bugsnag-js into your own code, and ensure Bugsnag is loaded right at the start.
All of that said, I support making the change to make this work better, because for some people loading Bugsnag async from CDN is a reasonable trade-off.

That makes sense, and helps a good deal, thanks @ConradIrwin. It sounds like we could improve the current implementation and thoroughly document the caveats and process for effectively loading Bugsnag.js asynchronously. If I understood this completely, the caveats should be:

Synchronous loading is the only way to ensure that all errors are caught
Any code loaded before Bugsnag on older browsers can result in error report loss due to missing information and/or stack traces
If library users want to load Bugsnag asynchronously and support older browsers, the best experience would be to minify Bugsnag and load it before their code in their applications

Does that cover everything?

+1

We've updated our docs with suggestions for async loading in the bugsnag-js FAQ, which should help address this for now. Support for using a data-attribute might be a nice thing to consider for the future though.


CodeCov Badge

Add the magic to calculate code coverage using CodeCov, complete with badge in the README.
Issue #14

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@aa3f7a9). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #15   +/-   ##
=========================================
  Coverage          ?   22.33%
=========================================
  Files             ?        2
  Lines             ?      103
  Branches          ?        0
=========================================
  Hits              ?       23
  Misses            ?       80
  Partials          ?        0

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa3f7a9...39aa2ad. Read the comment docs.


CPT Spot Check

Database, with database schema change

[x] Show db.Column changes you have made to model/python file in Visual Studio Code

[x]  Show initialization data code in VSCode

[x] Demo delete database and run ./migrate.sh

[x] Demo corresponding schema change in SQLite3
[x] Demo initialization data captured in Column in SQLite3

Postman with /authentication screen

[x] Show /authenticate endpoint code in Visual Studio Code

[x] Show and Demo /authenticate in Postman…

[x] Demo calling to endpoint

[x] Show JSON data passed in call

[x] Show Response window

[x]  Show Cookie acquired window

[x] Cut/Copy/Paste Cookie into jwt.io and show decrypting payload

[x] postman with /api screen to access data under authentication

[x] Show /api CRUD code in Visual Studio Code, expecting READ/GET code

[x] Show and Demo /api READ/GET endpoint in Postman…

[x] Demo calling to endpoint that requires Cookie

[x]  Show Response/Data

[x] Demo Deleting cookie

[x]  Demo calling endpoint again

[x]  Show Response/Failure

Postman with /authentication screen

[x] Show /authenticate endpoint code in Visual Studio Code

[x] Show and Demo /authenticate in Postman…

[x] Demo calling to endpoint

[x] Show JSON data passed in call

[x] Show Response window

[x]  Show Cookie acquired window

[x] Cut/Copy/Paste Cookie into jwt.io and show decrypting payload


RTS workaround converting SIGTERM into SIGINT

This is important for graceful shutdown, cleaning up resources in
bracket statements.
Fixes #1697

I should actually throw to the main thread rather than raise SIGINT. That's what the RTS does. I should also upstream this to GHC (see TopHandler).

I'm working on a GHC patch that'll make this the default behavior of the RTS https://gitlab.haskell.org/DavidEichmann/ghc/-/tree/davide/sigterm

I've responded to comments by @newhoggy in https://github.com/input-output-hk/cardano-node/pull/3670


Confirm Output format examples cover the full spectrum

Make a list of most popular output configurations and ensure that examples exist in the chassis repo. output only, output + explainability, output+ explainability + drift, also across a DL and standard model representation.
Add a section in docs to point reader to examples.

clarifying point. make sure that the chassis docs cover export examples and that the notebook examples point back to the docs for autosupported items.

Modified scope of this to coincide with explainability support

Accepted as a roadmap item for v1.6 release (https://github.com/orgs/modzy/projects/4?pane=issue&itemId=33138982).


Crash / Infinite loop when target class constructor accepts self

Hi, stumbled into this:
<?php declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

class Test {
    public function __construct(string|self $value) {
        // copy-constructor-ish
    }
}

$mapper = (new CuyZ\Valinor\MapperBuilder)->mapper();

$test = $mapper->map(Test::class, ['value' => 'foo']); // string -> OK

$test = $mapper->map(Test::class, ['value' => $test]); // self -> OK

$test = $mapper->map(Test::class, ['value' => null]); // null -> FAIL

$ php test.php
PHP Fatal error:  Uncaught Error: Xdebug has detected a possible infinite loop, and aborted your script ...

Without Xdebug it just keeps running.

you'd need string | self | null

Let me clarify:
What is expected to happen?
Because null is not allowed as $value, the mapper is expected to throw MappingError.
This is what happens if self is removed from allowed types:
Uncaught CuyZ\Valinor\Mapper\TypeTreeMapperError: Could not map type `Test`. An error occurred at path value: Value null is not a valid string.

What actually happens?
The library enters infinite loop/recursion.
Program crashes when either time limit or memory limit is reached.


URIs: replace git protocol with https one for the github sources.

Use https instead of git because unauthenticated git protocol is disabled by github
Signed-off-by: Ihor Usyk<EMAIL_ADDRESS>

Acked-by: Volodymyr Babchuk<EMAIL_ADDRESS>

Reviewed-by: Ruslan Shymkevych<EMAIL_ADDRESS>


Requesting release of a new version

Please release a new version of this module. It currently uses https://github.com/corazawaf/coraza commit id, 8b909c7fc
This commit in that repo was released on January 17, Last release in this repo was on January 19.
This commit in corazawaf/coraza has a bug because of which it crashes on some inputs.
May 24 21:01:12 delbgp caddy[798842]: panic: runtime error: slice bounds out of range [177:0]
May 24 21:01:12 delbgp caddy[798842]: goroutine 52252 [running]:
May 24 21:01:12 delbgp caddy[798842]: github.com/corazawaf/coraza/v3/internal/corazawaf.(*bodyBufferReader).Read(0xc000f7c6f0, {0xc00044a000?, 0xa6?, 0x41786d?})
May 24 21:01:12 delbgp caddy[798842]:         github.com/corazawaf/coraza/v3@v3.0.0-20230117071831-8b909c7fc345/internal/corazawaf/body_buffer.go:98 +0x139
May 24 21:01:12 delbgp caddy[798842]: io.discard.ReadFrom({}, {0x260ada0, 0xc000f7c6f0})
May 24 21:01:12 delbgp caddy[798842]:         io/io.go:651 +0x72
May 24 21:01:12 delbgp caddy[798842]: io.copyBuffer({0x26139a0, 0x36c5ae0}, {0x260ada0, 0xc000f7c6f0}, {0xc0008c0000, 0x8000, 0x8000})
May 24 21:01:12 delbgp caddy[798842]:         io/io.go:413 +0x14b
May 24 21:01:12 delbgp caddy[798842]: io.(*multiReader).writeToWithBuffer(0xc000c3e1f8, {0x26139a0, 0x36c5ae0}, {0xc0008c0000, 0x8000, 0x8000})
May 24 21:01:12 delbgp caddy[798842]:         io/multi.go:54 +0xe5
May 24 21:01:12 delbgp caddy[798842]: io.(*multiReader).WriteTo(0x1fa9120?, {0x26139a0, 0x36c5ae0})
May 24 21:01:12 delbgp caddy[798842]:         io/multi.go:45 +0x56
May 24 21:01:12 delbgp caddy[798842]: io.copyBuffer({0x26139a0, 0x36c5ae0}, {0x7fb28b212b38, 0xc0011151d0}, {0x0, 0x0, 0x0})
May 24 21:01:12 delbgp caddy[798842]:         io/io.go:409 +0x16e
May 24 21:01:12 delbgp caddy[798842]: io.Copy(...)
May 24 21:01:12 delbgp caddy[798842]:         io/io.go:386
May 24 21:01:12 delbgp caddy[798842]: net/http.(*transferWriter).doBodyCopy(0xc0007ee140, {0x26139a0?, 0x36c5ae0?}, {0x7fb28b212b38?, 0xc0011151d0?})
May 24 21:01:12 delbgp caddy[798842]:         net/http/transfer.go:412 +0x4d
May 24 21:01:12 delbgp caddy[798842]: net/http.(*transferWriter).writeBody(0xc0007ee140, {0x26094a0, 0xc00067de00})
May 24 21:01:12 delbgp caddy[798842]:         net/http/transfer.go:375 +0x428
May 24 21:01:12 delbgp caddy[798842]: net/http.(*Request).write(0xc001087a00, {0x26094a0, 0xc00067de00}, 0x0, 0x0, 0x0)
May 24 21:01:12 delbgp caddy[798842]:         net/http/request.go:705 +0xb46
May 24 21:01:12 delbgp caddy[798842]: net/http.(*persistConn).writeLoop(0xc0006399e0)
May 24 21:01:12 delbgp caddy[798842]:         net/http/transport.go:2413 +0x171
May 24 21:01:12 delbgp caddy[798842]: created by net/http.(*Transport).dialConn
May 24 21:01:12 delbgp caddy[798842]:         net/http/transport.go:1766 +0x173d
May 24 21:01:12 delbgp systemd[1]: caddy.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
May 24 21:01:12 delbgp systemd[1]: caddy.service: Failed with result 'exit-code'.
May 24 21:01:12 delbgp systemd[1]: caddy.service: Consumed 6.991s CPU time.

This read method in that commit and the most recent commit look almost the same. I tried running fuzzers on the new code and the old code for a few minutes and couldn't find a valid input that will break this code and I'll try running fuzzer overnight again.
For now, Please consider releasing a new version of this module which uses an updated version of corazawaf/coraza. Thanks!

Done https://github.com/corazawaf/coraza-caddy/releases/tag/v2.0.0-rc.1


State changes of a nested object after initialization of a main object

I can't have ability to change the state object. This is a bug or feature?
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
        pydantic version: 1.5
       pydantic compiled: False
            install path: /home/user/PycharmProjects/****/venv/lib/python3.6/site-packages/pydantic
          python version: 3.6.9 (default, Apr 18 2020, 01:56:04)  [GCC 8.4.0]
                platform: Linux-5.3.0-7648-generic-x86_64-with-Ubuntu-18.04-bionic
optional deps. installed: []

...

from pydantic import BaseModel

class Car(BaseModel):
     color = 'blue'

class Person(BaseModel):
     car: Car = None

>>> car = Car()
>>> person = Person(car=car)
>>> car is person.car
False

# I would like to have an ability to change the state of the field such way
>>> car.color = 'black'
>>> person.car.color  # I would like to get 'black'
'blue'

To change the state of the field in the Person model, you would simply need to modify that value:
>>> person.car.color = 'black'
>>> person
Person(car=Car(color='black'))

rather than the one outside of/unrelated to the one passed to person.

@StephenBrown2 Yes, this obviously works, but it would be more convenient to be able to change the state of the Car instance (as I wrote above). For example, Django allows you to use this way.

@nikolay-sokolov-qs Personally I'm not in favor of that way, it seems risky to me to be able to modify an unrelated instance and have other models affected, so I guess I won't be using Django. @samuelcolvin should have the final say on if pydantic should allow values by reference, though.

The fix would be very simple, it would be as simple as changing
https://github.com/samuelcolvin/pydantic/blob/881df8bde7bfc90e3a349c420d0b0b7d46237d59/pydantic/main.py#L575
You could even do this on your own custom base model.
The problem is that when you create a model by parsing input data everything get's copied - mostly that's correct since input data can be mutated to match the model and it would be weird in the raw input object was changed by that.
I think it would be too confusing to break that rule here.


Change local path to use the gtksourceview-3.0 path

Installing the theme to the gtksourceview-3.0 local path allows the usage in all apps that use GtkSourceView to render code (like Meld), not just gedit.
Implements suggestion of #11

I've dived more into this and actually the best thing to do is duplicate the theme installation, as gedit does not use the gtksourceview-3.0 path.


Move to Babel 6

Babel changed quite a bit from 5 to 6 (babel-cli, transform-plugins-modules, just to mention a few of the changes).
We should probably find the time to upgrade the build and possibly remove browserify.

PR? ;-)

Wow. Time flies. Babel is now at 7.9.0. I'll see if I find the time to upgrade a little.


Dependency: TCG ACPI spec work

Enhance TPM2 with start method for SBI ecall to support fTPM.

This seems out of scope for BRS? Shouldn't support for fTPM be started in the SBI spec?

Probably should be started in a security spec - https://github.com/riscv-non-isa/riscv-os-a-see/issues/21, which could be here or part of a platform spec. The SBI work and subsequent ECR against the TCG ACPI spec would be a dependency.


Docusaurus website renders without theme

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Prerequisites

[X] I'm using the latest version of Docusaurus.
[X] I have tried the npm run clear or yarn clear command.
[X] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
[ ] I have tried creating a repro with https://new.docusaurus.io.
[X] I have read the console error message carefully (if applicable).

Description
This problem is most likely related to the fact that the data-theme attribute for the html tag isn't being set on the first render, causing the whole website to appear without a theme for a few seconds (you can test this by assigning an empty string to data-theme property).
I've tried updating the version, but that didn't fix the issue.
Default theme is also present in the config file.

Reproducible demo
No response
Steps to reproduce

Navigate to https://postgres.ai/
You will see that the website loads without the theme

Expected behavior
Website loads with theme defined in the config:
themeConfig: {
   colorMode: {
     defaultMode: 'dark',
  },

Actual behavior
Website loads without theme and sets the correct theme after a few seconds.
Your environment

Public source code: https://gitlab.com/postgres-ai/docs
Public site URL: https://postgres.ai/
Docusaurus version used: 2.0.0-rc.1

Self-service

[ ] I'd be willing to fix this bug myself.

Thank you. Yes, this issue isn't reproducible locally with docusaurus build and docusaurus serve.

Thanks, @slorber!


cannot produce the results in table 4

Hello
Thank you for the great work.
I am trying to re-produce the results in table 4 of the paper however I cannot.

should we test the model only on the validation set of CLIVE and KonIQ or on the whole dataset?

can you share the trained models,
P2P-BM (Sec. 4.1) , P2P-RM (Sec. 4.2), and P2P-FM (Sec. 4.4), that can produce those results?

The results that I get from running the pre-trained model are far less than what is reported on the paper.

Hi, thank you for reporting.
We faced legal issues trying to make public a considerable number of images. Therefore, we removed those images.
We have to re-split the database and retrain the model after. We didn't share the original pretrained models because the split is different.
However, the model should give a similar performance. I am writing a journal paper and more pre-trained models will be released soon. Also note the performance also vary with the split of CLIVE and KonIQ, we will report the performance on the whole database instead in the journal paper.
Thank you again and more discussion is welcome!

Hi, thank you for reporting.
We faced legal issues trying to make public a considerable number of images. Therefore, we removed those images.
We have to re-split the database and retrain the model after. We didn't share the original pretrained models because the split is different.
However, the model should give a similar performance. I am writing a journal paper and more pre-trained models will be released soon. Also note the performance also vary with the split of CLIVE and KonIQ, we will report the performance on the whole database instead in the journal paper.
Thank you again and more discussion is welcome!

Thanks for the reply.
I understand that the new version will come out soon, but for the time being, can you please clarify if the provided results in the paper are on the splits of CLIVE and KonIQ or on the whole datasets?

Thanks for the reply.
I understand that the new version will come out soon, but for the time being, can you please clarify if the provided results in the paper are on the splits of CLIVE and KonIQ or on the whole datasets?

Yes, I am writing a document for that. Just uploaded the original pretrained model and will publish the google colab soon

Yes, I am writing a document for that. Just uploaded the original pretrained model and will publish the google colab soon

@seyeeet  Please follow this google colab to reproduce the results. Thanks!

@seyeeet  Please follow this google colab to reproduce the results. Thanks!


Collect site code

Is the site code even distributed by alfred?

Yes, since gluon-v2015.1, here the commit https://github.com/freifunk-gluon/gluon/commit/3b3b0bf52163904be467f76567916cc1f785dba8

Thanks I guess..


translate function not returning proper type [with CodeSandBox example]

If I use react-localize-redux with typescript I will encounter type issue when passing the value to the 'translate' function and expecting to use returned string as a placeholder text for input form element.
Typescript is complaining that return value wont be a string but this instead:

I've noticed that this issue had already been reported (issue #145, #148, #149 if I am not mistaken) so I decided to improve the report by making the codesandbox example as it is still not fixed in the newest version.
  ARRRGHHHHH!


(Platform: WSL 2) "error: No such file or directory (os error 2)" during cargo publish

Problem
cargo publish yields error: No such file or directory (os error 2) without any further diagnostics.
Steps
Unclear. On my machine:
chillup $ cargo clean
chillup $ cargo build && cargo build --release
(snip)
chillup $ cargo publish -vvv --no-verify
    Updating crates.io index
   Packaging chillup v0.3.0 (/mnt/c/Users/Cokem/workspace/chillup)
   Archiving .cargo_vcs_info.json
   Archiving .gitignore
   Archiving Cargo.lock
   Archiving Cargo.toml
   Archiving Cargo.toml.orig
   Archiving README.md
   Archiving src/main.rs
   Uploading chillup v0.3.0 (/mnt/c/Users/Cokem/workspace/chillup)
error: No such file or directory (os error 2)

Possible Solution(s)
n/a - need better diags
Notes
Output of cargo version:
cargo 1.44.1 (88ba85757 2020-06-11)
rustc 1.44.1 (c7087fe00 2020-06-17)
wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu                 Running         2

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:        18.04
Codename:       bionic

Note: This package already exists - I expect publish to update it.
Note: I have successfully published on WSL with this machine already, but this is my first time trying since upgrading to WSL 2.
Note: I generated a new crates.io auth key as a guess for the issue, which did not solve the problem

Thanks for the report! I think we may have merged some improvements to the error message in more recent versions of Cargo, can you try publication with nightly Cargo and see if the error message changes?

Hey @alexcrichton , thanks for the response.
I've done rustup default nightly and rustup update, but it's unclear to me if I'm actually on a recent nightly release:
chillup $ cargo -V
cargo 1.46.0-nightly (c26576f9a 2020-06-23)
chillup $ cargo publish -vvv --no-verify
    Updating crates.io index
   Packaging chillup v0.3.0 (/mnt/c/Users/Cokem/workspace/chillup)
   Archiving .cargo_vcs_info.json
   Archiving .gitignore
   Archiving Cargo.lock
   Archiving Cargo.toml
   Archiving Cargo.toml.orig
   Archiving README.md
   Archiving src/main.rs
   Uploading chillup v0.3.0 (/mnt/c/Users/Cokem/workspace/chillup)
error: No such file or directory (os error 2)

Is this in-line with your expectations?

@alexcrichton do you have access to a Windows machine with WSL2?  For some reason, mine won't let me upgrade.  I tried publishing in WSL1, and it seemed fine.  However, AIUI, WSL2 has completely redone how the filesystem mounting works, and  I would be suspicious if something related to that is an issue.

I do have a Windows machine but apparently it won't let me update to the latest Windows to get WSL2. I'm not entirely sure why (it just points me here and says "no action needed", but I can try this in the future if it lets me update.

Hey @alexcrichton, I had the same experience. The easiest way to force the upgrade is to join the windows insider program on one of the release rings.
To be honest, I don't recommend doing it. Microsoft forces you to enable telemetry to join insider ring. The only reason I've done this is to get access to docker wsl backend.
I would be happy to gather more diagnostics, or if someone does want to force this upgrade, happy to provide help with that. I'm @cokemonkey111:matrix.org.
Cheers,

You can force update with Update Assistant: https://www.microsoft.com/en-gb/software-download/windows10
I have access to WSL2 so I can help if you need.
I believe this fails in WSL2 because you are in fact using "remote" directory. Unlike WSL, WSL2 is a virtual machine so it cannot directly access host directories. To workaround that Windows partitions are available as /mnt/<letter> through 9P protocol. This has serious downsides like very small throughput, big latency and issues with file locks.
My general recommendation with WSL2 is to do all the work on directories inside the image and use /mnt/<letter> only for copying between the VM and host.

@mati865 thanks for the insights. I've managed to publish from a directory in ~ on first attempt.
Leaving issue open as cargo should provide better diags when this happens. For next steps it's probably needed to isolate what area of code breaks down. I can easily reproduce this and happy to help.
Cheers,

I bumped into this same issue yesterday and I did some digging. I traced the problem to the point where the publish code checks the tarball metadata, but I don't really know how to fix it:
diff --git i/crates/crates-io/lib.rs w/crates/crates-io/lib.rs
index 3b8b30b30..2561b27c9 100644
--- i/crates/crates-io/lib.rs
+++ w/crates/crates-io/lib.rs
@@ -169,7 +169,14 @@ impl Registry {
         //      <json request> (metadata for the package)
         //      <le u32 of tarball>
         //      <source tarball>
-        let stat = tarball.metadata()?;
+        let stat = match tarball.metadata() {
+            Ok(stat) => stat,
+            Err(err) => bail!(
+                "failed to read tarball metadata for file {:?}: {}",
+                tarball,
+                err
+            ),
+        };
         let header = {
             let mut w = Vec::new();
             w.extend(&(json.len() as u32).to_le_bytes());
(END)

Applying that diff, I get the following output:
   Uploading netlify_toml v1.0.0-alpha.1 (/mnt/c/Users/David/source/repos/netlify-toml-rs)
error: failed to read tarball metadata for file File { fd: 3, path: "/mnt/c/Users/David/source/repos/netlify-toml-rs/target/package/netlify_toml-1.0.0-alpha.1.crate", read: true, write: true }: No such file or directory (os error 2)

The supposed missing file can be read correctly otherwise:
➜  cargo git:(master) ✗ file /mnt/c/Users/David/source/repos/netlify-toml-rs/target/package/netlify_toml-1.0.0-alpha.1.crate
/mnt/c/Users/David/source/repos/netlify-toml-rs/target/package/netlify_toml-1.0.0-alpha.1.crate: gzip compressed data, was "netlify_toml-1.0.0-alpha.1.crate", max compression, original size modulo 2^32 36352

Thanks @calavera for digging in.  I can finally update my Windows machine to WSL2.  I have posted a proposed fix at #8950, which has some more details on why this is happening.

Hey all, it seems this bug showed up again. Happy to start another issue for this if we want since I believe it's a different part of the code, just same symptoms.
user@wsl-system:/mnt/e/projects/mylibrary$ cargo version
cargo 1.67.0-nightly (ba607b23d 2022-11-22)
user@wsl-system:/mnt/e/projects/mylibrary$ cargo publish --dry-run --verbose
<...output snipped...>
Finished dev [optimized + debuginfo] target(s) in 7.61s
error: could not learn metadata for: `/mnt/e/projects/mylibrary/target/package/mylibrary-0.1.1.crate`

Caused by:
  No such file or directory (os error 2)
user@wsl-system:/mnt/e/projects/mylibrary$

Relevant strace:
lseek(3, 0, SEEK_SET)                   = 0
rename("/mnt/e/projects/mylibrary/target/package/.mylibrary-0.1.1.crate", "/mnt/e/projects/mylibrary/target/package/mylibrary-0.1.1.crate") = 0
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, 0x7ffe02e1fc90) = -1 ENOENT (No such file or directory)
flock(3, LOCK_UN)                       = 0
close(3)                                = 0

It looks like it was reintroduced late last month, in commit 81f0f63. I figure this could be solved most easily by:

obtaining file metadata from the file by the new name (std::fs::metadata(&dst_path))
obtaining file metadata from the file before renaming it (dst.file().metadata() after the dst.seek() call above)

Happy to submit a PR with one of those solutions, it may just take me a bit to get a cargo dev environment setup.
I agree with @mati865's general conclusion that WSL handles 9p files oddly - it seems to lose the ability to stat a file through a file descriptor after renaming it (see strace above).
I've wrote a small test for it below, along with the output for my system.
Summary:

Result
Test Case

Pass
Windows (NTFS)

Pass
WSL2 Linux (ext4)

Pass
WSL2 Linux (ext4 - mounted over SSHFS from a native Linux system)

Fail
WSL2 Linux (9p - Windows drive)

Fail
WSL2 Linux (9p - mounted over SSHFS from localhost)

renamed_file_metadata.rs:
use std::fs;
#[cfg(unix)]
use std::os::unix::fs::MetadataExt;

fn main() {
    // create file
    // rename it by path to something else
    // get file metadata from original file descriptor

    const FILE_SRC: &str = "test_file_src.txt";
    const FILE_DST: &str = "test_file_dst.txt";

    eprintln!("cwd: {}", std::env::current_dir().unwrap().display());
    let f = fs::File::create(FILE_SRC).expect("error creating original file");

    let fm = f.metadata().expect("unable to get new file's metadata");
    #[cfg(unix)]
    eprintln!("current file's dev/inode before rename: {}/{}", fm.dev(), fm.ino());
    fs::rename(FILE_SRC, FILE_DST).expect("error renaming file");

    #[cfg(unix)] {
        eprintln!("current file's dev/inode after rename: {}/{}", fm.dev(), fm.ino());

        match fs::File::open(FILE_DST) {
            Ok(fr) => {
                // seems to be allowed on ext4, not p9
                let fr = fr.metadata().expect("unable to fetch metadata for newly renamed file");
                eprintln!("renamed file's dev/inode: {}/{}", fr.dev(), fr.ino());
            },
            Err(e) => {
                eprintln!("renamed file's dev/inode: (failed: {:?})", e);
            }
        }
    }
    eprintln!("Result: able to get renamed file's metadata from original FD/Handle: {:?}", f.metadata().is_ok());
}

My system versions + test output
PS E:\> cmd /c ver
Microsoft Windows [Version 10.0.19045.2130]
PS E:\> rustc renamed_file_metadata.rs
PS E:\> .\renamed_file_metadata.exe
cwd: E:\
able to get renamed file's metadata from original FD/Handle: true
PS E:\>

user@wsl-system:~$ uname -a
Linux wsl-system <IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
user@wsl-system:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu Jammy Jellyfish (development branch)
Release:        22.04
Codename:       jammy
user@wsl-system:~$ df -T
Filesystem     Type   1K-blocks       Used Available Use% Mounted on
/dev/sdb       ext4   263174212   14469452 235266604   6% /
tmpfs          tmpfs    9815288          0   9815288   0% /mnt/wsl
tools          9p     402653180  329823164  72830016  82% /init
none           tmpfs    9815288          4   9815284   1% /run
none           tmpfs    9815288          0   9815288   0% /run/lock
none           tmpfs    9815288          0   9815288   0% /run/shm
none           tmpfs    9815288          0   9815288   0% /run/user
tmpfs          tmpfs    9815288          0   9815288   0% /sys/fs/cgroup
drivers        9p     402653180  329823164  72830016  82% /usr/lib/wsl/drivers
lib            9p     402653180  329823164  72830016  82% /usr/lib/wsl/lib
C:\            9p     402653180  329823164  72830016  82% /mnt/c
D:\            9p<PHONE_NUMBER><PHONE_NUMBER> 288767928  85% /mnt/d
E:\            9p     536869884  503601612  33268272  94% /mnt/e
user@wsl-system:~$ rustc renamed_file_metadata.rs
user@wsl-system:~$ ~/renamed_file_metadata
cwd: /home/user
current file's dev/inode before rename: 2064/68907
current file's dev/inode after rename: 2064/68907
renamed file's dev/inode: 2064/68907
able to get renamed file's metadata from original FD/Handle: true
user@wsl-system:~$ cd /mnt/e
user@wsl-system:/mnt/e$ ~/renamed_file_metadata
cwd: /mnt/e
current file's dev/inode before rename: 48/3377699721142538
current file's dev/inode after rename: 48/3377699721142538
renamed file's dev/inode: (failed: Os { code: 2, kind: NotFound, message: "No such file or directory" })
able to get renamed file's metadata from original FD/Handle: false
user@wsl-system:/mnt/e$

tl;dr appears related to WSL NTFS mounts, workaround is git clone elsewhere then cargo publish
Using Ubuntu 22 on WSL2, I attempted to cargo publish (within Ubuntu 22) using a working directory that has an underlying NTFS file system managed by Windows 11.
$ cargo clean
$ cargo publish --verbose --dry-run
...
error: could not learn metadata for: `/mnt/c/Users/user1/Projects/super-speedy-syslog-searcher/target/package/super_speedy_syslog_searcher-0.3.54.crate`

The .crate file is accessible and touchable within Ubuntu 22.
$ file ./target/package/super_speedy_syslog_searcher-0.3.54.crate
./target/package/super_speedy_syslog_searcher-0.3.54.crate: gzip compressed data, was "super_speedy_syslog_searcher-0.3.54.crate", max compression, original size modulo 2^32 1919488

$ ls -las ./target/package/super_speedy_syslog_searcher-0.3.54.crate
-rwxrwxrwx 1 ulug ulug 303591 Mar 17 22:11 ./target/package/super_speedy_syslog_searcher-0.3.54.crate

$ touch ./target/package/super_speedy_syslog_searcher-0.3.54.crate

I tried cargo publish from different path under the same NTFS mount (git clone the repository, run cargo publish --dry-run). The same error occurred.
This appears related to NTFS mounts used by WSL2 Linux
Workaround
git clone elsewhere. I used a path under /tmp which is not backed by Windows NTFS. From there, cargo publish succeeded.
Context
$ cargo --version
cargo 1.67.1 (8ecd4f20a 2023-01-10)

$ uname -a
Linux host1 <IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux


Fix argument error when running dumpscript

Without this fix, the dumpscript command fail:
manage.py dumpscript auth.User
[...]
  File "/usr/lib/python2.7/site-packages/django_extensions-1.7.4-py2.7.egg/django_extensions/management/commands/dumpscript.py", line 95, in handle
    app_labels = options['appname']
KeyError: 'appname'

Coverage increased (+0.004%) to 37.565% when pulling f0d026bb5637b281a580611c230501a0b8a556e1 on steph-ben:master into af9f78c5935b61afaaadd2a989df2bddfab58f0b on django-extensions:master.

We should catch this in our tests. So we can also see which versions of Django are effected.
For this specific issue can't we not fix this in add_arguments ?


Update free-software-testing-books.md

Hi,
Just updated my name against the booklet Mobile Testing: Ready Reckoner for which I am the co-author. Thanks!

Merged, thanks.


[HOLD PR#34498] [$500] Bank account - Form is not saved with new changes after coming back to it

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.36
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4279485
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:
Pre-requisite: user must be logged in and have created a workspace

Go to Workspaces > Select Workspace > Bank account
Start and follow the add BA flow with testing credentials until you reach de Beneficial owners step
Tap on the back button to go back to Personal information page
Change the first and last name
Tap on the back button again to go back to Company information page
Tap on Save & continue button

Expected Result:
The Personal information page should be edited with the last data entered
Actual Result:
The Personal information page is not edited with the last data entered
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[x] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/afcf8d00-0c56-4afb-9f61-cfa513622d62
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0114287c47132d2711
Upwork Job ID:<PHONE_NUMBER>193392128
Last Price Increase: 2024-02-04

@Krishna2323 Thanks for the update. Your RCA is about right. However the solution is not fixing the root cause. I think it would be better to update reimbursementAccount.draftStep when going back so that if you are editing the requestor info the draft step should be reset to the previous step i.e. CompanyStep. Can you please look into that?

@s77rt
Proposal
Please re-state the problem that we are trying to solve in this issue.
After navigating back in the bank account setup, the changed fields are not persisted unless you hit save and continue. If you press back again, your changes are lost.
What is the root cause of that problem?
The current draft value logic is wonky!
We are actually overwriting the draft each time, with the current reimbursement account data:
https://github.com/Expensify/App/blob/7f4cdce48d7246380da7bf860fa928bae89bfa89/src/pages/ReimbursementAccount/ReimbursementAccountPage.js#L178
When we update the draft with the logic here.
https://github.com/Expensify/App/blob/0eb6d02b12569c42eca494d96c0c5f15eaa0b26f/src/pages/ReimbursementAccount/ReimbursementAccountPage.js#L214
However, at the moment reimbursementAccount.draftStep is always 1 screen behind. If you are on the Requestor page, reimbursementAccount.draftStep says Company page. This is because it doesn't update until we hit 'Save and continue' and the service returns us back the previous step to merge into  fromOnyx.
The way this allows the draft data to be saved in the happy paths, is that it's not overriding the draft in https://github.com/Expensify/App/blob/0eb6d02b12569c42eca494d96c0c5f15eaa0b26f/src/pages/ReimbursementAccount/ReimbursementAccountPage.js#L216 because when it calls getFieldsForStep it gets the fields for the previous screen, which doesn't override the current draft screen values. It looks like it works.
However, when you hit the back button, now the draftStep is actually also the current route, and getFieldsForStep gets the correct fields for the current screen. And it will keep overwriting the onyx draft data you enter with the latest saved onyx data. You can get out of this step by going back one screen, and then hitting save and continue again to let the service update reimbursementAccount.draftStep to the previous screen.
What changes do you think we should make in order to solve the problem?
I believe the best logic is to not maintain a reimbursementAccount.draftStep, and instead derive the step from the current route - we have existing logic for this. Then update the  logic to actually just merge in reimbursementAccountDraft into the reimbursementAccountDraft onyx store - our data and state variables are clean and aligned.
What alternative solutions did you explore? (Optional)
If we want to keep the reimbursementAccount.draftStep pattern being behind 1 screen, we can ensure the back button updates the reimbursementAccount.draftStep to the previous screen. We will need to created an ordered list in order to know what the previous screen is.

@jeremy-croff Thanks for the proposal. Your RCA is correct. Regarding the solution why would we need to merge the reimbursementAccountDraft with reimbursementAccount? That defeats the whole point of using back-end data as draft.

New draft should be coming from reimbursementAccount only
New draft coming from reimbursementAccount and reimbursementAccountDraft is same as just using reimbursementAccountDraft

@Krishna2323 I didn't mean that the solution is not working. I meant that it's not fixing the root cause i.e. a workaround.
PS: Please do not post code diffs

reimbursementAccountDraft

I chose to merge them onto eachother so that on initial render, draft gets created from reimbursementAccount. Then any user entered details get merged on top of it from the modified draft state in onyx.
This way draft is a complete object we can save and promote to reimbursement account on save and continue.

@jeremy-croff

This way draft is a complete object

I don't see the need for this. The draft merge process does not require you to supply all the fields. Can you clarify why this is needed?

reimbursementAccountDraft

I think you're eluding to a good point. And maybe my approach doesn't make sense after all.
I don't really understand why draft originally came from reimbursementAccount, and my solution followed that pattern with the changes merged on top of it to solve the bug.
However if theory crafting, If we only maintain what changed in draft, and not all what we see on screen (as we get from reimbursement account), there will always be possibility for inconsistency between the screen we intend to save and what's in the database. If we passed all the data, we would ensure what we intended to save is the latest saved.
My approach can still stand without merging onto eachother, and just maintaining draft instead like you pointed out. But then I want to dive deeper into understanding what the original intend was of merging the reimbursementAccount into draft.

@jeremy-croff That logic was introduced by https://github.com/Expensify/App/pull/28305 to fix https://github.com/Expensify/App/issues/25996. As long as the new approach still fixes the linked issue then we should be fine

@jeremy-croff That logic was introduced by #28305 to fix #25996. As long as the new approach still fixes the linked issue then we should be fine

This is very helpful.
So the purpose of putting ReimbursementAccount in draft is so that service side formatting gets applied to the draft data as that it what we see on the screen. Making the state accurate on back button. I think my fix does not solve this use case, as it will overwrite the formatted data with the draft.
New thoughts:
We'd only want to override ReimbursementAccountDraft with ReimbursementAccount from the previous step (identified as draftStep), since that's what just got saved and can be return differently from service..
However we run into an issue where draftStep is an outdated variable, breaking this logic.
I observe two things:
Each keystroke is running this code to update ReimbursementAccountDraft(prevStep) with ReimbursementAccount. And it only should be ran if ReimbursementAccount changes. That's 1 optimization for reducing unecessary onyx merges.
Then the second thing:
the draftStep is outdated. How can we fix this elegantly? We need a way to return to previous draftStep on the goBack method. I don't love an ordered list to derive the previous step. Maybe we just hardcode it for now based on the goBack logic in each relevant screen.

Proposal
Please re-state the problem that we are trying to solve in this issue.
draft changes not saved on back button flows
What is the root cause of that problem?
ReimbursementAccount.draftStep is outdated on back button
What changes do you think we should make in order to solve the problem?
Updated ReimbursementAccount.draftStep in onyx, can invoke it from the screens goBack method.
Using the BANK_ACCOUNT.STEP object keys to determine draftStep.
What alternative solutions did you explore? (Optional)
Optimize updateReimbursementAccountDraft to only apply ReimbursementAccount to draft on ReimbursementAccount changes rather than being tied to the render cycle of the entire component.

@Krishna2323

the problem is unnecessarily updating the draft in onyx, we update draft even on every key stroke, and the draft should only be updated when reimbursementAccount.draftStep is updated

This is a problem indeed but it's not the root problem. Updating the draft on every key stroke on its own is not a problem. It's a performance related issue but it's not our issue here.
The root cause here is that draftStep is stale (out-of-sync). If we get draftStep to have its correct value then even updating the drafts on every key stroke won't cause the bug.

@abzokhattab Thanks for the update. Your RCA is correct. The solution looks good to me.
🎀 👀 🎀 C+ reviewed
Link to proposal

@jeremy-croff Thanks for the follow up. You and @abzokhattab have very similar solutions. I think its fair to go with @abzokhattab for having the first complete proposal.

Proposal

So my first proposal had this as an alternate solution first, to update draftStep on goback.  while @abzokhattab did edit it from a wrong proposal to the correct one after my proposal, instead of him posting a new one. However he seemed to be the first one to identify to be able to use BANK_ACCOUNT.STEP keys for order, or the usePrevious hook. Which I quite like that solution and it makes sense for him to be assigned on it just based on that.

guys, I am sorry for not having a better process for this, but we will most likely tomorrow merge this big refactor for bank accounts https://github.com/Expensify/App/pull/34498
I will hold this issue for that and then we can see if its still repro there

Still will come off hold soon

https://github.com/Expensify/App/pull/34498 is merged. Seems that the bug is still reproducible
https://github.com/Expensify/App/assets/16493223/cbe85cc5-247d-46c4-8f47-55813c823d32

Yeah, from the doc that introduced these changes, it's only expected to save at each of the confirm steps:

User entered data is updated to the database at each of the “confirm” steps so leaving the flow before reaching the confirmation page of that specific step will cause the user to lose the data they entered thus far in that step

@kevinksullivan @joekaufmanexpensify @anmurali - as these issues are being created by Applause, I suspect some updated regression test scripts need to be passed over to them to update/add/remove based on the new refactored flow. Who's taking care of that for the project?

Agreed. I think the behavior here is a bit odd. But the order of steps taken to identify this behavior doesn't feel to me like something many/any customers will do in this flow. I don't expect many people will get to the first confirmation page, then go back and edit their name, and then not proceed with saving on the form. This feels like one where there'd be benefit to seeing if anyone actually experiences this.

as these issues are being created by Applause, I suspect some updated regression test scripts need to be passed over to them to update/add/remove based on the new refactored flow. Who's taking care of that for the project?

I haven't been involved much in this project since helping with the initial design. My understanding is @anmurali has been leading it. Though, latest update in the issue makes it seem like the implementation is still in progress.

I will go ahead and close this since I think this is expected and if we want to change this its more of a feature request.
I am sorry it was not caught earlier.

Cool, thanks @joekaufmanexpensify. I'll comment on the tracker.