Graphql transformer does not generate query filters for nested type objects

Note: If your issue/bug is regarding the AWS Amplify Console service, please log it in the
Amplify Console GitHub Issue Tracker

Describe the bug
I am trying to test appsync auto generated resolvers and queries for below schema. The problem I am facing, is that the query filter doesn't include filter for nested type ("enterprise" , it entered into dynamo as a Map attribute ).
type TestAuth @model
    @key(fields: ["pk", "sk"])
{
######################################
    pk                 :ID!
    sk                 :ID!
    enterprise         :EnterpriseData
}

type EnterpriseData {
    tenantId           :String
    tenantName         :String
}

Any suggestion or workaround would be greatly helpful. I don't want to write customise filters.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

@vkumarvs You can model your transformer schema like the following:
type TestAuth @model
@key(fields: ["pk", "sk"])
{
######################################
pk :ID!
sk :ID!
enterprise :EnterpriseData @connection
}

type EnterpriseData @model {
tenantId :String
tenantName :String
}

And then from your client you can call a query  in this format:
Query testAuthENt {
  getTestAuth(filter: ...) {
    enterprise(filter: ...) {

    }
  }
}

@vkumarvs You can model your transformer schema like the following:
type TestAuth @model
@key(fields: ["pk", "sk"])
{
######################################
pk :ID!
sk :ID!
enterprise :EnterpriseData @connection
}

type EnterpriseData @model {
tenantId :String
tenantName :String
}

And then from your client you can call a query in this format:
Query testAuthENt {
  getTestAuth(filter: ...) {
    enterprise(filter: ...) {

    }
  }
}

Thank you @kaustavghosh06 for reply but I don't want to use two tables for this. My data will remain in single table.
More importantly , it seems amplify doesn't autogenerate nested type filtering, nested types makes my single table schema look clean but I can't query those fields. It sound to me a feature request.

@kaustavghosh06  any update on this?

@vkumarvs That's correct. DynamoDB doesn't provide filtering capabilities for complex JSON objects. For advanced filtering you could either use Elasticsearch along with your DDB using @searchable dirctive or use two models.

@kaustavghosh06 I will explore @searchable directive but graphql support for nested objects would have been amazing. I just need to fetch all my complex objects rows that are keyed and include the rows that matches my nested attributes field.
Creating multiple tables to satisfy only this requirement sound little harsh to me.
My schema is something like below.
type Factory
@model
@key(fields: ["pk", "sk"])
) {
pk: ID!
sk: ID!
dataType: DataType!
######################################
workstation: WorkStationData #input types nested objects
region: RegionData #input type nested object
}
I would have listed all the nested object based on my PK and sk and then further filter based on nested object (workstations) attribute.)

type Factory
@model
@searchable
@key(fields: ["pk", "sk"])
) {
pk: ID!
sk: ID!
dataType: DataType!
######################################
workstation: WorkStationData #input types nested objects
region: RegionData #input type nested object
}
I used searchable directive and the filtering code generated by Tranformer doesn't include workstation object.
export type SearchableFactoryFilterInput = {
pk?: SearchableIDFilterInput | null,
sk?: SearchableIDFilterInput | null,
and?: Array< SearchableFactoryFilterInput | null > | null,
or?: Array< SearchableFactoryFilterInput | null > | null,
not?: SearchableFactoryFilterInput | null,
};
It only contains pk and sk so I do not have choice to get data based on nested filtering. Any suggestion?

same problem here, would be great to have @searchable working with nested fields

Same request here , it would be great to have @searchable working with nested fields.

+1

+1

+1
Important feature! We need to setup our own search instance to get this working

per @undefobj we should also think about this for the _version and _deleted filters when using GraphQL API + DataStore

+1

+1


feat: allow strings for coreml assets

This allows non-asset files to be used as coreml assets so downloaded coreml models can be used.

Confirmed working, ready to be merged


the Topic header of the request was not specified and was required

When I try and use the production certificate it gives me 'the Topic header of the request was not specified and was required' I did change host from push.Development to push.Production but it doesn't work.

Do you mean apns-topic? Gaurun can set it in TOML configuration.
https://github.com/mercari/gaurun/blob/master/CONFIGURATION.md#ios-section

I think, it mean "does gaurun support APNs inteface using JWT authorization ?"
may be not.

@kyken gaurun does not support JWT authentication now.

@cubicdaiya
I thought about it, but it may be that simply multiple topics were attached to his certification.
I had a same problem but i have resolved using TOML setting :)

Since there is no activity for a while and I think this issue can be resolved by TOML setting, I'll close this issue. Thank you. (FYI, gaurun supports JWT authorization for APNs today.)


Homepage hero, intermediate heading typography, dividers

Added 2021 hero graphic
Added slightly smaller heading styles
Added Divider component

📝Changed routes:

/

(view full size)

Commit 49b5f7bf01acbd34c053a79408fa7d99f5952fc5 (https://unihackwebsite-2qzt1rjjb.vercel.app).


Update hackernewSummarizeBot.py

add concurrent

related to https://github.com/bdim404/HackerNews-Summarize-Telegram-Bot/issues/36


Accounts fix

Fixed string format on accounts app. Also added a check for already existing emails. Fixed static validation on backend.

Thanks merged


indent: fix nested dangling lines that don't use parens

We weren't handling cases like:

if foo ||
foo &&
foo {
code()
}

We were indenting line 4 too far because we weren't following the
dangling lines all the way up to line 1. There can be arbitrary
amounts of nested indents with no parentheses, so to find the indent
inside the "if" block you must follow all dangling lines to the
beginning of the statement.
I also fixed a couple other minor indent issues:

fix an edge case with multi-line case statements where we weren't
indenting the final line with the colon
fix go--end-of-line to skip multiple /* */ style comments at the
end of the line

@go-mode-bot run

@go-mode-bot run

@go-mode-bot run

@go-mode-bot run

@go-mode-bot run

@go-mode-bot run

@go-mode-bot run

trigger new notification


Update to newer docker env syntax

Description
This PR modifies the example Dockerfile to use the newer syntax for defining environment variables, since the older form ENV K=V is deprecated.

Deleted due to wrong repo for the PR branch.


SuperDebug is not reactive when using data.form from +page.server

Hello !
I've tried to use the SuperDebug component from Superforms, but it seems it isn't reactive to the form changes.
My form and the validation system works also as intended, but the SuperDebug only load with initial state, and doesn't reflect any change to the fields nor their validation state.
I've simply imported the component as per Superform's doc :
import SuperDebug from 'sveltekit-superforms/client/SuperDebug.svelte';
Then used it with data.form provided by the +page.server.ts:
<Form.Root method="POST" form={data.form} {options} {schema} action="?/submit" let:config>
  <!-- Rest of the form-->
</Form.Root>

<SuperDebug data={data.form} />

Trying to use Superforms $form store as shown below, simple doesn't work as its type is unexpected by the Form.Root component :
<script>
  //...
 const { form } = superForm(data.form);
</script>

<Form.Root method="POST" {$form} {options} {schema} action="?/submit" let:config>
<!-- ... -->

And give this error :
Type '{ method: string; $form: { bundleName: string; formats: { name: string; width: number; height: number; }[]; }; options: Partial<{ id: string; applyAction: boolean; invalidateAll: boolean; resetForm: boolean | (() => boolean); ... 24 more ...; warnings: { ...; }; }>; schema: ZodObject<...>; action: string; }' is not assignable to type '{ schema: Validation; form: SuperValidated<Validation, any>; options?: Partial<{ id: string; applyAction: boolean; invalidateAll: boolean; resetForm: boolean | (() => boolean); ... 24 more ...; warnings: { ...; }; }> | undefined; ... 218 more ...; 'on:fullscreenerror'?: EventHandler<...> | ... 1 more ... | undefined...'.
  Object literal may only specify known properties, but '$form' does not exist in type '{ schema: Validation; form: SuperValidated<Validation, any>; options?: Partial<{ id: string; applyAction: boolean; invalidateAll: boolean; resetForm: boolean | (() => boolean); ... 24 more ...; warnings: { ...; }; }> | undefined; ... 218 more ...; 'on:fullscreenerror'?: EventHandler<...> | ... 1 more ... | undefined...'. Did you mean to write 'form'?

I've just seen the debug props on <Form.Root/> to activated Superdebug inline. I'll mark this as close as I wasn't aware of this option.


Version Packages

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
<EMAIL_ADDRESS>Minor Changes

#2370 7f695b10 Thanks @thomasheyenbrock! - Include the context provider for the explorer from @graphiql/react and replace the local state for the nav stack of the docs with methods provided by hooks from @graphiql/react.

Patch Changes

Updated dependencies [7f695b10]:

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>Patch Changes

#2370 7f695b10 Thanks @thomasheyenbrock! - Add a context with provider component and hooks that manages the state related to the docs/explorer.

The latest changes of this PR are not available as canary, since there are no linked changesets for this PR.

Merging this is blocked currently, I found a bug introduced in #2404 that I'm going to fix first!

@thomasheyenbrock is it going to be an issue when I cut these releases? We will need it for the LSP server and vscode graphql

@thomasheyenbrock in a manual regression experiment, the latest netlify deploy from the last merge is looking fine

great working adding context support so gradually! not an easy feat. so many exciting capabilities this will unlock!

can I ask @thomasheyenbrock what made these minor changes? was there any API breaking changes (props?) or just new features?

I did a minor version for @graphiql/toolkit and @graphiql/react since they obviously got new stuff. I also did a minor bump for graphiql because it's a more fundamental change in terms of the functionality under the hood. I know that a lot of folks merge in patch updates automatically without looking at them, so my hope was to create an incentive for giving this a closer look before upgrading to maybe catch unexpected bugs that might have been introduced with these changes.

ok, that's good to know! perhaps this minor version can denote when we officially started using @graphiql/toolkit and @graphiql/react. this would be the most visible change to users who aren't looking into or using internals.
if anyone starts complaining about window.GraphiQL.<some method> no longer working or other internal changes, they are already using an internal and unsupported interface! However, in these cases, we should consider what they were using it for, and how they might solve that problem differently.
Also, if we are at any point adding/removing any library exports (at the main/module export level), these should be considered non-internal API functions & components, and a minor version could denote a breaking change in one of these lesser-used interfaces as well.


Adds support for using async inside the babel runtime

Summary
Allows using async functions inside the jest codebases.
Test plan
I'd like to hope that the babel team have all the tests for this 👍 - assuming all is 📗 on tests then I think the transpiling is good

@dmitriiabramov will give you a hug for this. I've been fighting him, but I guess now it is 2 against one, so let's do it! I smell some refactors of old Promise code coming.

Current coverage is 89.36% (diff: 100%)

No coverage report found for master at 90262b1.

Powered by Codecov. Last update 90262b1...addba86

thank you! ❤


Generated test environment config prevents classes from being partially doubled in tests

Checklist

[x] Upgrade Jets: Are you using the latest version of Jets? This allows Jets to fix issues fast. There's a jets upgrade command that makes this a simple task. There's also an Upgrading Guide: http://rubyonjets.com/docs/upgrading/
[x] Reproducibility: Are you reporting a bug others will be able to reproduce and not asking a question. If you're unsure or want to ask a question, do so on https://community.boltops.com
[x] Code sample: Have you put together a code sample to reproduce the issue and make it available?  Code samples help speed up fixes dramatically. If it's an easily reproducible issue, then code samples are not needed. If you're unsure, please include a code sample.

My Environment

Software
Version

macOS
14.4.1 (23E224)

Jets
5.0.12

Ruby
3.2.3

Expected Behaviour
The following RSpec code prevents the actual implementation of ClassName#method_name from being run in the test example.
allow(ClassName).to receive(:method_name).and_raise 'Whoopsy daisy!'

Current Behavior
The original implementation of ClassName#method_name is run.
Step-by-step reproduction instructions

I created an example application that demonstrates the issue. I may have experienced this bug more consistently in controller tests, so the example app partially mocks a non-controller class inside of a controller spec.

Clone the git repository linked to below.
Make sure you're on branch main.
Run bundle exec rspec spec/controllers/demo_controller_spec.rb on the command line. NOTE: You can write a similar spec in your own test application by creating a class outside of the Jets class hierarchy, mocking a class method on that class, and writing an expectation for the mocked behavior.

You will see test output similar to this:

Failing test output
DemoController
  GET #index
    when the utility class is not stubbed
      executes the original method
    when the utility class is partially stubbed to raise an error
      rescues the error and returns a 500 status (FAILED - 1)

Failures:

  1) DemoController GET #index when the utility class is partially stubbed to raise an error rescues the error and returns a 500 status
     Failure/Error: expect { get '/demo' }.to raise_error 'Whoopsy daisy!'
       expected Exception with "Whoopsy daisy!" but nothing was raised
     # ./spec/controllers/demo_controller_spec.rb:18:in `block (4 levels) in <top (required)>'

Finished in 0.03077 seconds (files took 0.93326 seconds to load)
2 examples, 1 failure

Failed examples:

rspec ./spec/controllers/demo_controller_spec.rb:17 # DemoController GET #index when the utility class is partially stubbed to raise an error rescues the error and returns a 500 status

How to write your own test application

Create a new API app like so: jets new class-caching-error-demo --mode api
Write a new non-controller class outside of the Jets hierarchy in a file such as app/utilities/demo_utility.rb. This class will be referred to as "the utility class" from here on out.
Call a method of the utility class in a controller action.
Partially mock a class method of the utility class in the controller spec.
Write a test example that expects the mocked behavior and place it in the same scope as the partial mock.

Code Sample
Git repository of test application
Solution Suggestion

Change the template for the test application environment so that configuration option cache_classes is set to true, not false. Setting this option to false makes it so that the partially mocked class is reloaded without the mock when it's used in the application code under test.
The Jets default is also the opposite of the Rails default. In Rails, cache_classes is set to true in testing environments unless Spring is installed. Generated Jets apps do not come with Spring. Please refer to the documentation of config.cache_classes in Rails 7.0. I have chosen to refer to the Rails 7.0 manual because Jets 5.0.12 includes libraries from Rails <IP_ADDRESS>.
The test app's Git repo has a branch called fix-test-config, which has cache_classes set to true, contrary to the Jets default. The tests in demo_controller_spec.rb pass on that branch:

Output of tests succeeding with fixed test environment configuration
DemoController
  GET #index
    when the utility class is not stubbed
      executes the original method
    when the utility class is partially stubbed to raise an error
      rescues the error and returns a 500 status

Finished in 0.01534 seconds (files took 0.87718 seconds to load)
2 examples, 0 failures

@tongueroo Was there a specific reason why cache_classes was set to false by default? I haven't experienced any ill effects from enabling it in my project. I've only experienced the benefits of partial class doubles working again. Please let me know if there is anything I can do to improve the pull request that I created: #722.

This was resolved by #722. Thanks, @tongueroo!


Update the kind of error the CFE produces for the failing patterns in irrefutable contexts

The runtime error that the CFE produces on a failed pattern match in an irrefutable context should be changed. Currently, the CFE uses ReachabilityError as a placeholder.
The following is a relevant and very helpful fragment from an offline conversation with @lrhn. Thank you for the clear and elaborate guidance, as always, Lasse!

First of all, a pattern in an irrefutable context cannot fail to match. That should be a compile-time error.
If it fails anyway, it's either because a ! or as failed, and then it's a TypeError as usual.
Or it's a list or map pattern which doesn't have the required elements/keys, in which case ... I'd be fine with just doing list[2] and letting it throw, but map["key"] won't throw, it just returns null, and we should throw if the key isn't there, even if the value pattern would accept null. So we do need to decide what to throw in that case.
Not inventing a new error would be nice. ReachabilityError is definitely a strawman name 🙂
I'd probably go with StateError. The state of the object being matched does not support the operation required (having a [2] element or ["key"] entry).
It's not an ArgumentError, because there is no function and no argument.
It's could be UnsupportedError, but that's usually reserved for an object which will never support that operation, and a list or map can be updated to have the value.
So, StateError matches, a state-based inability to support the operation, not an inherent inability like adding to an unmodifiable list.
That means it requires a message. I'd go with:
  StateError("List pattern requires ${_patternMinLength} elements, list has only ${list.length}")
  StateError("Map pattern requires key not provided by map value.")

It's a good distinction to look at which things would throw in a refutable pattern too, and which would fail it.
The implicit downcast from dynamic probably won't happen in a refutable pattern, we'll do a real type check first and reject instead. However, a failing implicit downcast should throw what it always throws, not something new just because it happens in a pattern. That would just be confusing, since the downcast is not really related to the pattern, it's more of a general property of putting dynamic into a typed context.
(We could argue that checking a typed pattern against a dynamic matched value type is treated as a refutable pattern in an irrefutable context, and it is a pattern failure. That would also be a consistent story, we'll have
to decide in the specification of coercions. But if so, we should choose what to throw, and TypeError is still
the best choice, so it's really just a philosophical distinction.)
The as and ! patterns will throw in refutable patterns too, and it'll be a TypeError, just like a failing as or ! outside of a pattern. Again, no need to do something new.
A throwing getter or other member, including a contravariant return type check, will also throw as normal.
It's really only failing list and map patterns that are pattern failures, not just normal errors that happen on the way to doing the pattern match.
They are the only patterns which can still be refuted in an irrefutable context where the pattern has been successfully type checked against the static matched value type, because they check properties not guaranteed by the type.
Still think StateError is a good choice for those.

As of https://dart-review.googlesource.com/c/sdk/+/291063, a StateError is used in place of the ReachabilityError. The message string doesn't provide any details though and simply says "Pattern matching error".


API express app routing & middleware improvements

This PR contains some cleanup that was leftover from the original 1.0 refactor of all the middleware and split of Ghost into multiple express apps.
These 2 commits are relatively small, but they make it possible to A) find the API routes B) understand the middleware a bit more and C) move forward from here with further refactors.
I have a 3rd commit that moves all of the API endpoints into an /endpoints/ folder. That one is much more involved and I will hold off until unsplash is merged to prevent conflicts.
2 other things which can be done after this PR:

moving towards have individual routers for each API endpoint, e.g.

var postsRouter = express.Router({mergeParams: true});
postsRouter.get('/', mw.authenticatePublic, api.http(api.posts.browse));
postsRouter.post('/', mw.authenticatePrivate, api.http(api.posts.add));
...
apiRouter.use('/posts/', postsRouter);

This is beneficial because the more we break things down into subfunctions, the more API we end up with, and the more we can move behaviour into the internal apps. At the moment the API router is a monolith, but that's not desirable long term.

Revisiting the authentication middleware, particularly for the schedules API endpoint, because we have multiple usecases for "client-specific" api endpoints.

This all makes sense to me 👍

@AileenCGN This PR is non-urgent, but would be nice to have merged in after unsplash goes out. The concepts of what I'm changing have been approved by Kate, but the work itself needs a review and a little testing by a different pair of eyes.


Please add support for multipart messages

libsodium supports multipart messages through the crypto_sign_init / crypto_sign_update / crypto_sign_final_{create,verify} functions. Please add support for them to sodiumoxide. The underlying algorithm is subtly different, so I can't just easily use crypto_sign and get the same results.
Thanks :)

Hashing the message with sha512 and signing the hash should give you the same results. Does that work for you?

Unfortunately not. Ed25519 requires a different context identifier.

Tried that. Unforatunately it doesn't work, because crypto_sign_{init,update,final} and crypto_sign_detached hash the messages differently :(
See sign.c, prehashed is true for init/update/final and false for detached.

uh this never got merged, did it?

Not yet, will probably get merged this week.
On Sun, 29 Apr 2018 at 18:52, Arvid E. Picciani<EMAIL_ADDRESS>wrote:

uh this never got merged, did it?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/dnaq/sodiumoxide/issues/166#issuecomment-385264975,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPVBd7v_VOHxHxRP7KKgKPfaIKVA_0bks5tte_dgaJpZM4OO8Y9
.


python3Packages.skodaconnect: 1.1.17 -> 1.1.18

Motivation for this change
https://github.com/lendy007/skodaconnect/releases/tag/1.1.18
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 158525 run on x86_64-linux 1

2 packages built:

python310Packages.skodaconnect
python39Packages.skodaconnect


Characters in the token id generated is not equal to the varchar character limit in token table

@webreinvent commented on Fri Sep 23 2016
Here's what I did:

ace auth:setup to setup authentication, it created migration as well which includes tokens table.
Changed authenticator from authenticator: 'session', to authenticator: 'api',
Used following code to generate token:

const user = yield User.find(1)
const token = yield request.auth.generate(user)

if I print this token it contains 121 characters while in tokens table, column token has only varchar(40) 40 characters.

@webreinvent Can u share the generated token?

yeah sure eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJwYXlsb2FkIjoxLCJpYXQiOjE0NzQ2NTMwODV9.KjwELbXTFiOdTIz3Ta8Vsv4rTbzxPZxxMvMX3MP-7Yo

This is a JWT token for sure. Can u share the complete config file config/auth.js.

oh, my bad forgot to upload the changed config file to server. Sorry! You can close the issues.
can you guide me about how to make the api call? I am using php curl to get response <my api url>?token=<token> but how to authenticate using the token passed in the middleware?

It is thenAuthentication header Bearer <API TOKEN>


The downloaded file is empty

The downloaded file is empty!
The downloaded file is empty！

Github notifications never seem to work for me so sorry for not getting this message!
Also strange? I have tested this before and it has worked. Probably something related to the asset lib.

Just checked, this shouldn't even be broken at all. I'm on the right git hash for the library.
I don't understand why it breaks to be honest.


Change canary back to start both worker and starter by default

What changed?
Change canary back to start both worker and starter by default

Why?
In a previous PR, I changed the default to start worker only. I realized that this is a breaking change as some users told me they are using canary in some release version already. So it's better to not break them.
On another hand, I think starting worker only is useful for manual testing, which can be done already since we have the mode argument. But the default behavior should start all for simplicity.

How did you test it?
Local test

Potential risks

Release notes

Documentation Changes

Pull Request Test Coverage Report for Build 32f07f74-cc43-4af5-9d71-eaf0656b75fb

0 of 0   changed or added relevant lines in 0 files are covered.
12 unchanged lines in 6 files lost coverage.
Overall coverage increased (+0.06%) to 56.846%

Files with Coverage Reduction
New Missed Lines
%

service/history/queue/timer_queue_processor_base.go
1
78.6%

common/task/fifoTaskScheduler.go
2
84.54%

common/task/parallelTaskProcessor.go
2
92.75%

common/task/weightedRoundRobinTaskScheduler.go
2
89.64%

service/history/shard/context.go
2
66.05%

common/cache/lru.go
3
90.73%

Totals

Change from base Build efc8bfde-4a91-4787-b992-79f9af303d11:
0.06%

Covered Lines:
81539

Relevant Lines:
143439

💛  - Coveralls


SOLUTION TO MULTIPLE ERRORS!

I found a lot of people on here posting different errors they were receiving when running the script. I am pretty sure I have had all of them at least once.
I found that in the main folder containing the script was a folder called "sessions". This folder was HUGE (2.5-3GB), and I couldn't delete it. It always stated that the files were in use, even after killing the script and all instances of Chrome...
So, I got this program I used to use back in the day (I hear it was a Thursday) called Unlocker. It's old freeware that tries to - well, unlock files so that you can rename/move/delete them. It usually works wonders, but even that couldn't delete the sessions folder... BUT, when it failed to rename the folder (i thought it might be easier than deleting outright), the program asked if I wanted to try the operation at boot. I hit yes, and rebooted. Bob's your mother's brother!
The script works great!
I am still pretty new to Github, and only just learned python, but if someone benefits from this and knows what the hell they're doing, could you inform the dev of the issue? Or maybe "sticky" this to the issues or posts?

Am I seriously writing a solution as error number 404!! Ha!

Use the kill script in previous posts to completely kill Chrome and you can edit/delete the folder without having to use a 3rd party app

True! Good call. Though, I did a kill cmd to chrome, abd that didn't work for me personally. Not sure if it's a Google drive sync issue, or something random like that.

Using the script on MacOS Sonoma... Using Chromium 119.0.6025.0, disabled updates, 0 errors... On windows i remember i have to disable Google Updates or script comes unstable and unrunnable

Resolved my issues! Deeting the folder sessions (it was like 21GBs for me) solved it.

Wow this is also what was causing my issues. Thanks


Map is not working

The display on the bottom and the commands are working but the map is not showing in the escape menu

There is no provided map, that's separate. Use the links in the original forum post to find them.


"Cochirleanca", "Boboc", "Gara Bobocu", "Roșioru" and "Târlele" are listed in the drop-down menu

Description:
"Cochirleanca", "Boboc", "Gara Bobocu", "Roșioru" and "Târlele" are listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Cochirleanca" in the search bar.

Expected results
The location is listed in the drop-down menu as "Cochirleanca, Buzău(Cochirleanca)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Type "Boboc" in the search bar.

Expected results
The location is listed in the drop-down menu as "Boboc, Buzău(Cochirleanca)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 6
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 7
Type "Roșioru" in the search bar.

Expected results
The location is listed in the drop-down menu as "Roșioru, Buzău(Cochirleanca)".

Step 8
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 9
Type "Târlele" in the search bar.

Expected results
The location is listed in the drop-down menu as "Târlele, Buzău(Cochirleanca)".


The barcode/[barcode]/scsb route should return a record even if it is suppressed

https://github.com/pulibrary/bibdata/blob/27ce102fa72468467732dfe5d236d3d76b7b0d06/app/controllers/barcode_controller.rb#L22
Many records in ReCAP are suppressed. This route should not be checking to see if the bib is suppressed.

Sample barcode:<PHONE_NUMBER>5078

https://bibdata.princeton.edu/barcode/32101104202237/scsb


[Cosmos] remove double signatures on container methods

Addressing https://github.com/Azure/azure-sdk-for-python/issues/23355

API changes have been detected in azure-cosmos. You can review API changes here


Lock icon flash

This PR closes the first half of  #674
Lock Icon no longer flashes

the behavior where the previous challenge isn't showing a check has returned...

I was able to fix all the errors except the fact that the flash still occurs when coming back through the chapter a second time. I need to think a little more about this lgic to see if its even possible to prevent that behavior since the lock is now only considering progress and not the index on the second pass


keyboard accelerators don't work

VSCode Version: 1.1.1
OS Version: Windows 7, x64

Steps to Reproduce:

Open the editor, make sure it has focus (cursor is blinking).
Press and hold the Alt key
Observe the accelerator letters highlighted in the main menu on the top. Particularly the File menu got an underscore at F
While keeping to hold Alt press the F key

Expected: the "File" in the main menu to open
Actual: no action

Works for me in Win10 in vscode 1.4.0


sap.ui.layout.Splitter: Dragging splitters in wrong location in RTL mode

OpenUI5 version: Latest
Browser/version (+device/version): Latest versions of all general browsers
Any other tested browsers/devices(OK/FAIL):
URL (minimal example if possible): https://openui5.hana.ondemand.com/explored.html?sap-ui-language=ar#/sample/sap.ui.layout.sample.Splitter/preview
User/password (if required and possible - do not post any confidential information here):
Steps to reproduce the problem:

Drag one of the vertical splitter bars

What is the expected result? Expected that the highlighted dragging splitter bar is shown in the correct place.
What happens instead? The highlighted dragging splitter bar is offset and moving in the opposite direction. Note that it works as expected in LTR mode (e.g. https://openui5.hana.ondemand.com/explored.html#/sample/sap.ui.layout.sample.Splitter/preview)
Any other information? (attach screenshot if possible)

Thanks for reporting this issue! This seems to me like a bug.
I created an internal ticket<PHONE_NUMBER> and forwarded it to the responsible developer.
Once the issue is fixed, we will inform you.
Kind regards,
Janina

Hi,
thanks for reporting the issue. I'm not sure how that slipped during initial testing. Mea culpa.
The fix will be available in 1.24.6, 1.26.4 and of course 1.28.
Best regards,
Jens

Time Travel? :-)

"Latest stable release: 1.24.6 (2015-01-12)"

Thanks guys! Is there an updated estimate on when 1.26.x will be released?

1.26.x is already available as beta version, the validation phase will be finished around January 21st. That's the day when we can declare 1.26 as "stable" and will offer one or the other 1.26 version as new stable release.
However, the version that is being tested is 1.26.1, so when validation is successful (which is getting more and more likely as we approach the end of validation), then this means that this version - which has been available for weeks as preview release - is declared to be good enough for productive consumption, we just weren't sure all the time. :-)
If validation still will find a blocker, then there will be another patch fixing it and only this patch version will then be released as new stable release. Incidentally, 1.26.4 is scheduled for the same day (21st), so 1.) even when a blocker is found the date could be the same, just the version would be higher, and 2.) we'll anyway publish the latest patch version, so we'll offer at least 1.26.4 as first stable release even when validation shows in hindsight that all previous patches starting from 1.26.1 would have been stable enough.
Sufficiently confused? :-)
Anyway: expect January 21st or one or few day later as 1.26 release date.
But you can already use the available 1.26.2 beta for your development and testing, as it will be VERY close to the final release version and probably also retroactively be declared to be a stable version.

Thanks for all the details Andreas. We at SAS are interested in building the SDK as well as just using it, since we'll be contributing fixes back to you. Will the build tools be completed in time for the 1.26 release? It looks like JavaScript minification still isn't included. Thanks.

Will the build tools be completed in time for the 1.26 release? It looks like JavaScript minification still isn't included

Our grunt-openui5 plugin already offers to create preload files to package a library or component via the openui5_preload task. This also includes minification for JavaScript. In the current grunt build inside the openui5 project we use this task to create the library-preload files, but do not minify every single source file. I guess that's what you mean, right?

So the library-preload files are minimized, but the build does not produce another minified version of all the single files, right?
Well, this shouldn't be a major problem, as for productive performance-critical usage one should anyway not use the single files, but the preload files instead. The performance benefit of the preload files is in real life higher than the one of minifying the JS files and loadign them one by one, I think.
However, for SAS the usage might be a bit different, it would be good to know in case you also have good use for all the single files.

It was a combination of things:

docs/developing.md hadn't been updated to say it now supports JS minification, which started me on a bad assumption
the individual .js files aren't minified, which I don't think is a real issue for us, except that the generated bootstrap files (e.g. sap.ui.core.js) aren't minified like they have been in the past.
I glanced at the generated library-preload.json files and saw initial comments in them and assumed they weren't minified. I didn't look close enough to see that it's only the copyright comments in there, and the rest is minified.

Thanks for pointing that out. I will fix the developing guide.
Exactly, the copyright comments are preserved but files get minified using uglifyjs.
An optimized "sap-ui-core.js" is still an open point that has to be fixed. I just created an new issue ( https://github.com/SAP/openui5/issues/276) for it to keep track of it there.

Thanks for the follow-up Matthias.


npm build is broken

To build for deployment is broken. After running it, the files are messed up for some reason.

After you build and upload the dist folder to chrome, the popup will not display

Fixed this by adding  to the index.html for the popup. Apparently it was using a different encoding and not translating the characters correctly. The build now works.


[ISSUE #3173]Isolate Broker logs when multiple Broker services are deployed on the same machine.

Make sure set the target branch to develop
What is the purpose of the change
#3173
Brief changelog
XX
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage decreased (-0.06%) to 53.967% when pulling e0406b2aa42126cf7ff9067ae7bbd985652dfb82 on zhangjidi2016:broker_log into 9a9039e8dcc5659628b724f58981e30c377ab5c3 on apache:develop.

Codecov Report

Merging #3174 (764cfba) into develop (1e982af) will increase coverage by 0.03%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             develop    #3174      +/-   ##
=============================================
+ Coverage      47.84%   47.87%   +0.03%
+ Complexity      4555     4552       -3
=============================================
  Files            552      552
  Lines          36642    36524     -118
  Branches        4848     4819      -29
=============================================
- Hits           17530    17485      -45
+ Misses         16883    16819      -64
+ Partials        2229     2220       -9

Impacted Files
Coverage Δ

...java/org/apache/rocketmq/broker/BrokerStartup.java
5.55% <0.00%> (-0.12%)
:arrow_down:

...rocketmq/broker/pagecache/ManyMessageTransfer.java
36.36% <0.00%> (-9.80%)
:arrow_down:

.../rocketmq/broker/pagecache/OneMessageTransfer.java
24.00% <0.00%> (-9.34%)
:arrow_down:

...org/apache/rocketmq/common/stats/StatsItemSet.java
41.79% <0.00%> (-8.96%)
:arrow_down:

...ache/rocketmq/common/stats/MomentStatsItemSet.java
39.13% <0.00%> (-4.35%)
:arrow_down:

...rg/apache/rocketmq/remoting/netty/NettyLogger.java
16.32% <0.00%> (-2.73%)
:arrow_down:

...ache/rocketmq/store/AllocateMappedFileService.java
39.02% <0.00%> (-2.44%)
:arrow_down:

...a/org/apache/rocketmq/store/StoreStatsService.java
28.85% <0.00%> (-1.32%)
:arrow_down:

...he/rocketmq/client/impl/consumer/ProcessQueue.java
58.13% <0.00%> (-0.94%)
:arrow_down:

...e/rocketmq/client/impl/consumer/RebalanceImpl.java
40.23% <0.00%> (-0.79%)
:arrow_down:

... and 24 more

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 1e982af...764cfba. Read the comment docs.

IMO, Could it be configured as optional? Otherwise, the sudden change of log directory is very confused for users.

@RongtongJin @yuz10  can you review this pr again ?


fix(examples): Remove references to obsolete runtime argument

These build failures are getting a bit annoying. Can we maybe cache $GOPATH/pkg/mod and avoid the lengthy process of fetching dependencies on every build?

maybe this helps: https://restic.net/blog/2018-09-02/travis-build-cache

Yes, +1 to try caching go modules.

Ok - let me try adding some cache config as a separate PR.


Added minor fixes to README.md

Changes made to line number 9, 35, 47.

Thanks for your interest in contributing to this project! Please take a look at our contributing guide and check out our good first issue list to find an issue to help fix.


glitch adding sources to topic

1 - go to create new topic screen
2 - click on 'add media' button
3 - add the following collections from the 'featured & starred' tab:
U.S. Top Online News 2017
U.S. Top Digital Native News 2016
Left
Center Left
Center

4 - click on the 'search geographic collections' tab
5 - enter 'united states' into the search box
6 - try to click on either of the first two results
When I do this, the first set of featured collections works fine, but I get no response when I try to add the US geographic collections.  At some point after clicking around for a bit, I was able to get the US National collection button to work, but still not the US Local / Regional collection.  I eventually had to star the US Local / Regional collection and add it from that screen (which worked fine).  When reproducing to create this issue, I was able to add the US geographic collections fine if I added them before the featured collections.

this is likely fixed due to the media-picker updates. will confirm

@cindyloo -- did this end up being fixed? Perhaps this will be addressed in the refactor, #1875.


Error: Invalid value for module argument

When trying to migrate our configuration to 3.0.0, I ran into a syntax/type error. I tested this using the example from the documentation and it produces the same error:
Error: Invalid value for module argument

  on gclb/main.tf line 35, in module "gce-lb-https":
  35:   backends = {
  36:     default = {
  37:       description                     = null
  38:       protocol                        = "HTTP"
  39:       port                            = 443
  40:       port_name                       = "default-https"
  41:       timeout_sec                     = 10
  42:       connection_draining_timeout_sec = null
  43:       enable_cdn                      = false
  45:       health_check = {
  46:         check_interval_sec  = null
  47:         timeout_sec         = null
  48:         healthy_threshold   = null
  49:         unhealthy_threshold = null
  50:         request_path        = "/"
  51:         port                = 443
  52:         host                = null
  53:       }
  55:       groups = [
  56:         {
  57:           # Each node pool instance group should be added to the backend.
  58:           group                        = var.backend
  59:           balancing_mode               = null
  60:           capacity_scaler              = null
  61:           description                  = null
  62:           max_connections              = null
  63:           max_connections_per_instance = null
  64:           max_connections_per_endpoint = null
  65:           max_rate                     = null
  66:           max_rate_per_instance        = null
  67:           max_rate_per_endpoint        = null
  68:           max_utilization              = null
  69:         },
  70:       ]
  71:     }
  72:   }

The given value is not suitable for child module variable "backends" defined
at
.terraform/modules/lb.gce-lb-https/terraform-google-modules-terraform-google-lb-http-d65708d/variables.tf:62,1-20:
element "default": attribute "protocol": string required.

The error message at the end ("element "default": attribute "protocol": string required.") changes from one attribute to another when I re-run terraform apply:
element "default": attribute "protocol": string required.
element "default": attribute "enable_cdn": bool required.
element "default": attribute "timeout_sec": number required.
element "default": attribute "port": number required.

No matter what the message is, the type always is correct. e.g. in the error above, you see protocol is "HTTP", which is a string.
I've got the latest terraform:
$ terraform --version
Terraform v0.12.18

And I've pinned GoogleCloudPlatform/lb-http/google at version 3.0.0 (clearly because when I try 2.0.0 I get "argument "backend_params" is required" error which makes sense because that syntax changed).
Any ideas where to look on this one? I'm kinda stumped.

I have resolved this.
The errors were not pointing to the correct invalid value. The problem I had was that var.backend was a list(string) rather than a string. My solution was to map this:
       groups = [
         # Each node pool instance group should be added to the backend.
         for backend in var.backend:
         {
           group                        = backend
           balancing_mode               = null
           ...
         }
       ]


[Bug] Clicking the sort button more than twice causes it to lock up

Go onto any of the actor sheet tabs with items and use the automatic sort functionality. Clicking it once will arrange the items in ascending order, clicking it again will reverse the order, and clicking a third time does nothing. We'd expect this third click to revert back to ascending order, but instead the button stops working. Further clicks also do nothing.
This issue requires a full page refresh before it functions again. Closing the sheet does nothing.

I can't actually replicate this.


Delete override on templated methods

Template methods cannot be virtual because they can essentially populate the vtable infinitely. Override is accepted on templates, but it is ignored. A PR to dmd has been raised to make it an error [1] so that the user does not have false assumptions; that PR is currently blocked and will be unblocked by this PR.
[1] https://github.com/dlang/dmd/pull/15350

cc @rostyboost @CyberShadow .

LGTM but I do not have merge rights here.
Was there a deprecation cycle for this?

The dmd PR currently makes it an error, but I'll change it to a deprecation.


Manifest_admin.json file missing

There is a manifest_authors.json file - is that the correct one and the instructions need to be changed?  Or is there a file missing?

It is not missing. You need to clone the GitHub repo and the file will be inside the Manifest folder.

You need to clone the GitHub repo and the file will be inside the Manifest folder.

I cloned the repo and do not see manifest_admin.json file.


Remove usage of classLoader to init AppPaths (it breaks Quarkus platform integration tests with jdk8)

The Linux check has failed. Please check the logs.

jenkins retest this please

The Linux check has failed. Please check the logs.

The Linux check has failed. Please check the logs.

jenkins retest this please

The Linux check is successful.


[Question] Should vGPU action buttons and warning messages be removed from VM page in View mode ?

When navigating in Virual Machine / view mode -> vGPU Devices tab:

vGPU enable warning message is visible
vGPU list bulk actions and row actions are actionable

I think we should probably remove those elements, which are used in edit mode.
We have a similar behavior in PCI Devices tab.

webhook in pcidevices will block the removal. Move the issue out to 1.6.0


Encryption

Issue #, if available:
Description of changes:
Enabling default encryption on SNS, SQS and S3. Using AWS managed SSE, so no additional IAM changes needed. Tested the changes with a new product.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hi, Can you help to share more information of end to end testing with these changes following the form below?
**End-to-end ("e2e")**: These are broad tests of overall system behavior and coherence. Please test and confirms these itemsL
    1. Verify the stack is deployed successfully.
    2. Verify URL endpoint is up and running with no error.
    3. Subscribe to the product successfully and can visit landing page with no error.
    4. Create an account using landing page.
    5. Receive notification as a Seller.
    6. Receive notification as a Buyer.
    7. Verify new user record is created in dynamo DB.

In addition, can you add more comment around why the changes is needed and if there are any trade offs (e.g: SQS queue could not invoke lambda function from different AWS account if it is encrypted)


feat: measure startup delay and journey duration

Measures the startup time in epoch micros, which will be used by Heartbeat to measure the actual startup delay of the Node.js process.
Also the browser launch delay process is measured and reported in micros.
Also fixes https://github.com/elastic/synthetics/issues/412 where journey.duration.us is reported.

Journey end event
{"type":"journey/end","@timestamp":1677539972109132.8,"journey":{"name":"journey-0","id":"journey-0","status":"succeeded","duration":{"us":199580}},"root_fields":{"browser_delay_us":57378,"process_startup_epoch_us":1677539969494005,"os":{"platform":"darwin"},"package":{"name":"@elastic/synthetics","version":"1.0.0-beta.40"}},"payload":{"status":"succeeded"},"package_version":"1.0.0-beta.40"}

:robot: GitHub comments
Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.


RFC: Resources v2

Rendered
Status: ~80% figured out. The remaining 20% is concerning performance/architectural implications that we should be sure to understand before going forward.
This is a very large proposal, heavily influenced by concourse/concourse#1707 and with a lot of prior planning in concourse/concourse#534. The discussion in 534 was growing stale, which was the catalyst for this new RFC format. Please leave feedback on individual lines instead of commenting directly so that the number of open discussion threads dwindles down as the proposal stabilizes and improves.
TODOs:

[ ] https://github.com/concourse/rfcs/pull/1#discussion_r263907060

To be honest I wrote that it could include the prior version earlier but I
don't think it helps enough. I think the ancestral scan would be necessary
instead. So in this case it would just return commit 3 and Concourse
would know that the given version is deleted.
On Tue, Apr 17, 2018, 7:42 PM braa braa braa<EMAIL_ADDRESS>wrote:

@cwlbraa commented on this pull request.
In 01-resources-v2/proposal.md
https://github.com/concourse/rfcs/pull/1#discussion_r182273197:

+With spaces there will be more checks than ever. Right now, there's one
+container per recurring check. Can we reduce the container overhead here by
+requiring that resource checks be side-effect free and able to run in parallel?

+There may be substantial security implications for this.
+
+
+## Is destroy general enough to be a part of the interface?
+
+It may be the case that most resources cannot easily support destroy. One
+example is the git resource. It doesn't really make sense to destroy a
+commit. Even if it did (push -f?), it's a kind of weird workflow to support
+out of the box.
+
+Could we instead just have put and ensure that we check in such a way that
+deleted versions are automatically noticed? What would the overhead of this be?
Your example is slightly more difficult and more illustrative than what i
meant initially...

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/concourse/rfcs/pull/1#discussion_r182273197, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAHWBwc1ALLLo0IX1yhs1xkCweva_13ks5tpn3SgaJpZM4TO-Lt
.

I'm going to cut the scope of this RFC down a bit by removing all the stuff concerned with notifications. I think there's a lot more to explore there and it warrants its own RFC. I'd rather wrap up the new artifacts interface sooner so that we can get support for spaces out the door.
I also just realized we haven't at all discussed the idea of schema validation. I'm going to cut that out, too - we should be able to add that in later, again as a separate RFC.

I'm relieved to see the scope-decomposition.
For the version-explosion problem, do we have a good pathological example?

We implemented a v2 interface proof-of-concept for the s3 resource. The code can be found here.

A question I've thought of whether resources could add a provision capability as well. There are some resources where the remote service is ephemeral or at least unimportant to humans. Examples would be registering a webhook with Github, creating randomly-named blobstore directories, or creating and binding databases. I think OSBAPI might be able to serve in this role.
Arguing against: any provision could instead be modeled as a put to a provisioning resource. Existing examples including the bosh-deployment resource, which essentially provisions systems intended for further usage.
The inspiration for this thought bubble is watching over the shoulder of Knative Eventing. In Concourse terms, I think Knative Eventing somewhat mixes together the concerns of provisioning an outside service with configuration of source/params.

I've been doing a lot of thinking about this lately, and now I'm worried that baking a high-level concept like 'spaces' into the resource interface is the wrong direction. I think I've got a better idea that simplifies things down to a single resource interface, a lot like what we have today - and a plan to use this single interface to implement spaces, triggers (e.g. the time resource), notifications (e.g. Slack, GitHub status checks), and versioned artifacts (today's primary use of the interface).
There's a lot to go over here - I'm going to try and provide as much context as possible behind my thought process. I expect at least some of this to be confusing or unclear. Sorry in advance for the word vomit. 😅 Feel free to ask questions to clarify - I plan to open a new RFC as it's a significant enough departure from this proposal, so we might as well just open the discussion up here until then.
Triggers and the stampeding herd problem
With concourse/concourse#2386 we formalized how resource configs and their versions are stored abstractly, but this introduced a problem: now the time resource would cause a stampeding herd, as everyone who said interval: 10m would get the same history, so all their jobs would fire at once across the cluster. We fixed this by the introducing 'resource scopes' which allow resources to have their own version history exclusive to their pipeline resource definition.
Resource scopes proved challenging to implement and introduce a level of overhead that is only exacerbated by the addition of resource spaces to the model, as they both try to achieve similar things. This led us to try to rethink the time resource as an example of inbound notifications, or "triggers". The hope was by switching time to a different concept and interface we would get rid of the problem of 'shared version history' as we would just stop treating it like an artifact. Context: https://github.com/concourse/concourse/issues/3585 and https://github.com/concourse/concourse/issues/3595
But then I thought maybe we're over-complicating things by introducing a whole new interface. If you look at the time resource's implementation, what it's doing pretty much makes sense in isolation. It's just that we don't want to centralize the history - in fact we don't even really want to store the history. Maybe we just need a different way to use resources in a pipeline in this way?
Coincidentally, @chenbh opened https://github.com/concourse/concourse/issues/3572 around the same time we were thinking about this. What's interesting is here they still want to use a resource, but only as a trigger, and they don't want to fetch the bits. Sounds familiar! 🤔
That led me to think maybe the interface is fine, and we just need different ways to use resources in a pipeline. Maybe everything is just "resources" in the sense that they're all the inputs to your pipeline and still represent all external state, but maybe we just need to allow your pipeline to have different relationships with this state? Maybe everything just isn't versioned artifacts?
It's worth noting briefly that the stampeding herd problem still exists within a pipeline today, not just with globally shared history. Having all the jobs that point to a time trigger all fire at once doesn't seem great.
So what if you could associate a resource to a job, and have its checks always be relative to the last-used trigger "version" that the job used? That way each job naturally has its own interval, and we're still just using the time resource as it is. The stampeding herd problem is then solved at all levels, without the need for a new interface.
Spatial resources
If we go with v2 RFC as-is, all resources implicitly have to care about spaces. What does this 'trigger-only' workflow even mean for spaces? ...Should spaces just be optional?
What if spaces wasn't part of the interface at all? Just like we were able to implement triggers in terms of the resource interface, can we implement spaces in terms of it, too?
The meaning of check, get, and put map pretty well to the spaces themselves:

check: returns a 'version' for each space. We would just never give it a cursor version, and do a set diff against the result. Users can configure whatever filters they want in config to control which spaces are returned.
put: supports creation/deletion of spaces (i.e. git branches).
get: returns whatever data is useful for a given space.

What's nice is this makes the detecting of spaces a lot clearer, and supports explicit creation/deletion of the spaces themselves. The current proposal puts all of this into check which checks across all spaces and has to emit a reset event when one disappears. With this interface, the space is just no longer returned.
So, how would we use this to support spaces over an artifact resource like git?
We take the "versions" returned by the space check and toss them in the config of the artifact resource, like so:
space /check:
    {"uri":"..."}
 -> {"branch":"foo"}
    {"branch":"bar"}

artifact /check:
    {"uri":"..."} + {"branch":"foo"} = {"uri":"...","branch":"foo"}
 -> {"ref":"abcdef"}
    {"ref":"deadbeef"}

In this case, the git resource already understands branch: as part of its source: config, so it doesn't even have to change! I think this is common to lots of existing resources, actually - the things they would have been changed to "space" over are actually things they already support being pointed to in their source: config.
The interesting thing here is it uses the 'version' as a way to compose resources together. It actually feels pretty nice! Versions are already a public contract and are even shown to users directly in the UI.
What's really interesting about this is that by decoupling the space resource from the artifact resource, you could space over arbitrary things. At the end of the day you're just dynamically providing fields to source:. If you wanted to have a space for testing different kinds of arbitrary configuration, not just what the resource author predicted, you can do it by writing your own space resource.
This also removes the whole idea of a "default space". Now that resources don't have to implement spaces, it's not necessary to even think about as a resource type author. Either your source: is statically configured or dynamically modified via a space resource - as an author you don't know or care.
Another thing that's great about this is that, internally, everything is just back to resource configs and their versions. No more scopes, spaces, etc. - just resource configs and their associated versions. In this relationship, one resource config just results in another resource config being created.
Notifications
An early iteration of this RFC actually introduced notifications as a new part of the v2 interface, and they could be tied to artifact resources. This was so that things like GitHub status checks could be sent back with an associated version, so the notification resource knows what commit to apply the status check to.
So, what if we don't add a new interface for notifications, and we just use the 'version' as a communication mechanism between resources, just like we did for spaces? What if you could point a notification resource at an artifact resource, and have Concourse automatically run the notification resource when the artifact resource is used in a build?
This would work by taking the version of the artifact resource and tossing it in the config when invoking the put action of the notification resource, like so:
{
  "config": {
    # arbitrary user-specified config
    "repo": "concourse/concourse",

    # taken from the monitored resource
    "ref": "abcdef"
  },

  # provided by concourse
  "build": {"id": 123, "status": "failed", "job_name": "some-job", "url": "https://..."}
}

Overall proposal
I think we should go back to resources being a super simple and general check/get/put interface, and cut spaces out of the proposed interface. I think this RFC has run its course and I can open a new RFC with the simpler proposal. This new RFC would be a more incremental change on the existing interface, and it would still include things like version deletion and collecting all versions back in time. With spaces out of the picture we can finally make these changes without putting all our eggs in one basket.
The new proposal would introduce the general interface, and then describe how it would be interpreted to support 'versioned artifacts', as the interface is used for today, and also touch on the ideas around composability I covered above, ultimately so that the common interface isn't too tied to versioned artifacts. (For example, we may want to use a name other than 'version'.)
The challenging part of this approach is how we bubble these concepts up to users. The pipeline has to feel intuitive and not too repetitive. It shouldn't take a degree in YAML architecture to configure GitHub status checks. But the more I think about this, the more apparent the benefits become in terms of the mental model and internal structure. I think having a consistent model is paramount for Concourse's success (it's one of the founding principles).
Here are some key take-aways summarizing the general direction I think we should go:

Resources are general interfaces for interacting with external state.
Concourse pipelines define the relationship your pipeline has with this state.

versioning artifacts
emitting notifications
triggering jobs
fanning out across branches dynamically
configuring build matrixes

Resources receive a single config and can emit config fragments (née versions).
Resources can compose with each other by passing config fragments to each other.

Config fragments can feed into /check.

Space {uri} config -> {branch}...
Artifact {uri} config + space {branch} fragment -> {ref}...
Artifact {uri,branch} config + artifact {ref} fragment (of last seen version) -> {ref}...
Or: artifact {uri} config + space {branch} fragment + artifact {ref} fragment (of last seen version) -> {ref}...

Config fragments can feed into /get.

Artifact {uri,branch} config + artifact {ref} fragment = git clone {uri}; git checkout {ref}

Config fragments can feed into /put.

Notification {repo} config + artifact {ref} fragment = update GitHub status

Add pipeline functionality for trigger-only resources as another RFC.

These are resources whose checks run relative to their associated job's last use of the notification.

Add pipeline functionality for notifications as another RFC.

These are resources that are sidecar-ed onto another resource and follow its path through the pipeline.

Add pipeline functionality for spaces as another RFC.

These are resources that are referenced in tandem with an artifact resource to run against each of the config fragments returned by the space. Something like {get: foo, spaces: bar}.
Spaces are a pipeline-only add-on feature that users opt in to by composing resources explicitly.
Now we don't have to worry about backwards-compatibility, because now the jump from v1 to v2 is easy, and spaces don't fundamentally change the resource model.

Critically, those last 3 RFCs can be done with both the v1 and v2 interfaces. It's not so coupled anymore. If you subtract spaces from resources v2, a lot of it is boring protocol changes, plus things like "put can create/delete many versions". That all is pretty independent of the other RFCs. It's a bit clearer with v2, of course, since v2 has just "config", but for v1 we can say that 'versions' (config fragments) are shoved into 'source' (config).

Proposing we close this in favor of https://github.com/concourse/rfcs/pull/24, which is still a work in progress but at least the resource interface part is pretty close. :smile: I'll open separate RFCs for spaces/triggering/notifications after the resource interface portion of #24 is done. (Right now they're all in there together.)

Will the lengthy comment above somehow come across to the new proposal? It carries a lot of important context and food for thought.

@jchesterpivotal The new proposals will encompass everything covered there, yes, though at the moment in a bit of a dry sense - the RFCs just outline the 'what' whereas my comment earlier was kind of a brain dump/train of thought that led to it. Is there any particular part you feel I should make sure to incorporate? Maybe they could just reference my comment for context-building? :thinking:

Perhaps as a discussion document?
I'm concerned that lots of folks will overlook a detailed discussion on a closed PR.

@jchesterpivotal I've added a 'Previous Discussions' section to the new RFC: https://github.com/concourse/rfcs/pull/24/commits/0a805ec8425344ff1e5202a707b9c42d706c4388


For Safe Version 1.1.1, safeTxGas is always zero for multisend transactions

Description
If you're using Safe Version 1.1.1, safeTxGas from  is always zero from createTransaction
Environment

Safe Core SDK version: 2.0.0
Safe contract version: 1.1.1
Environment:

browser: chrome

Steps to reproduce

use a safe with version 1.1.1
create a multisend transaction with createTransaction
the transaction will have zero safeTxGas (this causes some transactions to fail with 1.1.1)

Expected result
the transaction should have non-zero safeTxGas
Additional context
It's probably because ethAdapter.estimateGas will error out from metamask with this message:
MetaMask - RPC Error: execution reverted: MultiSend should only be called via delegatecall

@germartinez I think I found the cause for this issue:
https://github.com/safe-global/safe-core-sdk/blob/399dbfca774cdc83b571b56583059e2fe5d18845/packages/safe-core-sdk/src/utils/transactions/gas.ts#L39
I think we need to pass the operation to this call.
I have the same issue when creating my updateSafe transactions using createTransaction(tx[])

This has been fixed


When using HTTP->HTTPS redirect on route, HTTPS calls require  X-Frowarded-Proto header.

Summary
We need redirect HTTP -> HTTPS, so we set a route's attributes: protocol = ["https"] , https_redirect_status_code = "301".
The expected behavior is Location: https://example.org header on HTTP calls and regular response on HTTPS, but HTTPS calls return Location: https://example.org too.
though if X-Frowarded-Proto: https is included in the request, then it works as expected.
No issues when both protocols are enabled.
Steps To Reproduce

curl -X PATCH  -H 'Content-Type:application/json' --data  '{"https_redirect_status_code": 301,"protocols":["https"]}' http://kong-admin-url:8001/routes/route_id
curl -X GET -I https://api.example.com/nice_endpoint

HTTP/1.1 301 Moved Permanently
Date: Tue, 02 Feb 2021 22:22:03 GMT
Content-Type: text/html
Content-Length: 134
Connection: keep-alive
Location: https://api.example.com/nice_endpoint
X-Kong-Response-Latency: 1
Server: kong/2.1.4

but
curl -X GET -H 'X-Forwarded-Proto: https' -I https://api.example.com/nice_endpoint
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: nginx/1.17.8
Date: Tue, 02 Feb 2021 22:31:17 GMT
Vary: Accept-Encoding
Allow: GET, OPTIONS
X-Frame-Options: SAMEORIGIN
Cache-Control: no-cache, no-store
Pragma: no-cache
Vary: Cookie
X-Kong-Upstream-Latency: 7
X-Kong-Proxy-Latency: 3
Via: kong/2.1.4

Additional Details & Logs
I suppose the line is the reason for the issue and maybe  this for grpc too.
We run Kong 2.1.4 on VM. I'm following this doc

Closing this bug, the reason was in LB configuration.