Client fails to receive a payment and does not recover

Describe the bug
I have the following system set up (all using Connext 4.2.0):

Indra node
Clients A and B that listen for incoming transfers (RECEIVE_TRANSFER_FINISHED_EVENT)

Upon receiving a transfer (with meta.sender carrying the xpub of the sender), these clients wait for 1s and then transfer the same amount back to the sender

Client C that ensures it has a deposit of 0.0002 ETH on startup

Once it has started up, is sends 0.0001 ETH to both, A and B
Client C also listens for incoming transfers and sends them back to the sender, just like A and B

After a few payments back and forth, client C logged this:
error: [NodeApiClient] Failed to execute callback while lock is held: Error: No multisig address exists for the given appInstanceId
    at Store.getMultisigAddressFromAppInstance (/opt/-/node_modules/@connext/cf-core/dist/src/store.js:53:15)
(node:1) UnhandledPromiseRejectionWarning: Error: No multisig address exists for the given appInstanceId
    at Store.getMultisigAddressFromAppInstance (/opt/-/node_modules/@connext/cf-core/dist/src/store.js:53:15)

It still continued to receive payments from A and was able to send payments back to A.
But it no longer received anything from B.
After a restart, client C logged the following when trying to run connext.connect(). Additional restarts don't help, it keeps logging the same (except with a different receovered 0x... address every time):
(node:1) UnhandledPromiseRejectionWarning: Error: Validating a signature with expected signer 0xBC692b38cBbBd891Fe8Cd2E256285E0785431c94 but recovered 0x5cF1c11753995a839c23E2c046B418B7D95985b2 for commitment hash 0xacc6811e57a47fd23dd275765f88b8e6f71c3a3a68739ed122a9d3c2c32b236b.
    at Object.assertIsValidSignature (/opt/-/node_modules/@connext/cf-core/dist/src/protocol/utils/signature-validator.js:13:15)
    at /opt/-/node_modules/@connext/cf-core/dist/src/protocol/propose.js:116:35
    at Generator.next (<anonymous>)
    at resume (/opt/-/node_modules/@connext/cf-core/dist/src/protocol/propose.js:8:44)
    at /opt/-/node_modules/@connext/cf-core/dist/src/protocol/propose.js:7:121
    at new Promise (<anonymous>)
    at Object.i.(anonymous function) [as next] (/opt/-/node_modules/@connext/cf-core/dist/src/protocol/propose.js:7:63)
    at ProtocolRunner.runProtocol (/opt/-/node_modules/@connext/cf-core/dist/src/machine/protocol-runner.js:75:39)
    at ProtocolRunner.runProtocolWithMessage (/opt/-/node_modules/@connext/cf-core/dist/src/machine/protocol-runner.js:42:21)
    at handleReceivedProtocolMessage (/opt/-/node_modules/@connext/cf-core/dist/src/message-handling/handle-protocol-message.js:26:63)
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

error: [ResolveConditionController] Failed to resolve linked transfer 0x508993e04ed4126f51461f7d3828d99ba3f36cc1f1cdea4801704adea029e805: Error: Failed to send message: Request timed out.
    at NodeApiClient.<anonymous> (/opt/-/node_modules/@connext/client/dist/node.js:278:23)
    at Generator.throw (<anonymous>)
    at rejected (/opt/-/node_modules/@connext/client/dist/node.js:6:65)
error: [ConnextConnect] Could not reclaim pending async transfers: Error: Failed to send message: Request timed out.... will attempt again on next connection

After the timeout, client C manages to continue, but when it then tries to deposit something into the state channel, that times out as well:
error: [DepositController] Error proposing app: Error: App proposal took longer than 90 seconds
    at Timeout.setTimeout [as _onTimeout] (/opt/-/node_modules/@connext/client/dist/lib/utils.js:50:90)
    at ontimeout (timers.js:436:11)
    at tryOnTimeout (timers.js:300:5)
    at listOnTimeout (timers.js:263:5)
    at Timer.processTimers (timers.js:223:10)

Your Environment

Client version used: 4.2.0
Node version used: 4.2.0
Chain used: Rinkeby
Operating System and version (desktop or mobile): macOS

Node logs (excerpt):
[Nest] 1   - 02/27/2020, 6:59:57 PM   [LockService] Failed to execute callback while lock is held: IO_SEND_AND_WAIT timed out after 90s waiting for counterparty reply in propose +238ms
Error: IO_SEND_AND_WAIT timed out after 90s waiting for counterparty reply in propose
    at eval (webpack:///./node_modules/@connext/cf-core/dist/src/node.js?:107:23)
    at async ProtocolRunner.runProtocol (webpack:///./node_modules/@connext/cf-core/dist/src/machine/protocol-runner.js?:80:33)
    at async ProposeInstallController.executeMethodImplementation (webpack:///./node_modules/@connext/cf-core/dist/src/methods/app-instance/propose-install/controller.js?:52:9)
[Nest] 1   - 02/27/2020, 6:59:57 PM   [LockService] Releasing lock for 0xC7c4175D538A7300f2cAc20AA613257C4F072Ab3 with secret b91e4102da31410fc2e71b7e8dfe0617
[Nest] 1   - 02/27/2020, 6:59:57 PM   [LockService] Failed to release the lock due to expired ttl: LockError: Unable to fully release the lock on resource "0xC7c4175D538A7300f2cAc20AA613257C4F072Ab3".;
[Nest] 1   - 02/27/2020, 6:59:57 PM   [LockService] No return value found from task with lockName: 0xC7c4175D538A7300f2cAc20AA613257C4F072Ab3, and failed to release due to expired ttl: Unable to fully release the lock on resource "0xC7c4175D538A7300f2cAc20AA613257C4F072Ab3". +1ms
LockError: Unable to fully release the lock on resource "0xC7c4175D538A7300f2cAc20AA613257C4F072Ab3".
    at loop (/root/node_modules/redlock/redlock.js:265:18)
    at tryCatcher (/root/node_modules/standard-as-callback/built/utils.js:11:23)
    at /root/node_modules/standard-as-callback/built/index.js:19:49
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
debug: [NatsMessagingService] Publishing _INBOX.U56JYA7BUUUQI5FCZ9HQYL.U56JYA7BUUUQI5FCZ9HQTP: {"err":"LockError: Unable to fully release the lock on resource \"0xC7c4175D538A7300f2cAc20AA613257C4F072Ab3\".","message":"Error during processor function: "}
[Nest] 1   - 02/27/2020, 6:59:57 PM   [MessagingProvider] Error processing message transfer.resolve-linked.xpub6EVQvyzRp3zNKiQwSNdc7yLCqoqXqAM9jYv724yGmLfDbUn3AAqPaunpxg1cJQgTbm3TCBVVLfvh4gkkAu6tA9uYUkWPJ2JWnPiU2RnBw7v: Unable to fully release the lock on resource "0xC7c4175D538A7300f2cAc20AA613257C4F072Ab3". +5ms
LockError: Unable to fully release the lock on resource "0xC7c4175D538A7300f2cAc20AA613257C4F072Ab3".
    at loop (/root/node_modules/redlock/redlock.js:265:18)
    at tryCatcher (/root/node_modules/standard-as-callback/built/utils.js:11:23)
    at /root/node_modules/standard-as-callback/built/index.js:19:49
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)


Integers with size greater than 57 bit result in failing precondition

package Test is

   type U58 is mod 2**58;

   type Message is
      message
         F1 : U58;
      end message;

end Test;

rflx-test-generic_message.adb:184:48: medium: precondition might fail, cannot prove Natural (((Offset'Pos (Ofst) + Value'Size - 1) / Byte'Size) * Byte'Size) < Long_Integer'Size - 1, in instantiation at rflx-test-message.ads:6

While the generated code for the simple example shown above can be successfully verified for integers up to a size of 57 bit, it fails with bigger ones. Increasing the proof steps and the timeout to --steps=100000 --timeout=120 did not help.

The failing precondition is needed to prevent some overflows in the implementation of Extract. I see no simple solution for this problem at the moment. This issue should be address in the context of #182.


Incorrect heuristic for text-logs separated by an unknown tranform

Admittedly a bit of a strange use-case, but if you have two separate log streams that should never be mixed in the same view, the only way to annotate that is with an unknown transform. Although the notion of transforms between text spaces is a bit weird, I believe this validly maps to our "Space" concepts (and it works!... aside from the heuristic issue).
Minimal repro:
rr.init("text", True)
rr.log_text_entry("foo", "Hello")
rr.log_unknown_transform("foo/bar")
rr.log_text_entry("foo/bar", "World")

The heuristic here creates and defaults to a spatial transform for the foo/bar space which seems wrong.

The expected behavior should be:

Also the fact that we have two "foo" spaces here seems wrong as well:

We no longer have unknown transforms, been like that for quite a while


[RFC] Add react-native-localize

Status
Open
New Dependency
Name: react-native-localize
URL

https://github.com/zoontek/react-native-localize
https://www.npmjs.com/package/react-native-localize

Focus
react-native-localize lets us access information about the user's locale and other preferences, e.g. calendar type. It's a small, actively-maintained lib, with loads of downloads per week.
We need it, or something like it, for this PR: #4241
Check List

[x] Have read over the source code, and we can maintain it
[x] Has had a release in the last year, or looks done and stable

Alternatives
No noteworth alternatives on npm.
We could always roll our own with just the data we need (current locale). I think this library is lightweight enough and generally useful enough that it makes sense to adopt, though.

I used this in the past and it's stable and lightweight
👍

[Resolved]

Come si installa? Grazie


Problems tokenizing Norwegian/Danish characters

I am training a Norwegian version AlBert and had problems tokenizing some special characters.
The Norwegian/Danish alphabet has three additional letters: æ, ø, å. The last letter "å" seem to be encoded as a common "a". It is a bit strange since the same library seem to be able to build dictionaries with words containing "å".
The following Colab-code (https://colab.research.google.com/drive/16VU4IBLrKPk54JjNW-KgpyNOVDdZhOKl) shows that the words "så" and "sa" is given the same id, even when both words exists in the vocabulary. The vocab-file used is from multilingual Bert. Tokenization in Bert has the same behaviour.

The bert tokenizer converts "å" and "ä" into a, and ö into "o". This happens in an attempt to remove accents from characters.
It's seems rather wasteful to tokenize the input , because the characters are still in the vocabulary, meaning that "så" and "sa" both takes up vocab space, but without any added value.
The issue comes from this function in the bert tokenizer: https://github.com/google-research/ALBERT/blob/master/tokenization.py#L333, which converts the text into "normalized form" (meaning that "å" is split into "a" and " ̊") and then removes the " ̊".

Thanks. I think I was able to solve the issue. Normalising the accented characters are tied to "do_lower_case=True" in FullTokenizer. Setting this parameter does no longer convert "så" to "sa".


 A backup of the staging database is in the #seattle channel on Slack.
It appears to be throwing on this line of the ReadOnlyApplicantProgramServiceImpl around Eligibility.
Does not occur in these cases

If you attempt to apply as a regular applicant
If you clear the database (/dev/seed) and use the generated programs it makes

Deployed Versions

Staging uses the latest snapshot image
Prod and Test are on v1.141.0 and don't appear to have the issue occur

Repro Steps

Run the app
Go to dev tools -> trusted intermediary
Scroll down to the client list and click on Applicant Dashboard for Dino, Big
Click apply to the Release testing program
You'll see an exception

Exception
! @83d5n94aj - Internal server error, for (GET) [/applicants/2458/programs/214/review] ->

play.api.http.HttpErrorHandlerExceptions$$anon$1: Execution exception[[RuntimeException: com.jayway.jsonpath.InvalidPathException: Filter: [?] can not be applied to primitives. Current context is:<PHONE_NUMBER>000]]
        at play.api.http.HttpErrorHandlerExceptions$.$anonfun$convertToPlayException$2(HttpErrorHandler.scala:381)
        at scala.Option.map(Option.scala:242)
        at play.api.http.HttpErrorHandlerExceptions$.convertToPlayException(HttpErrorHandler.scala:380)
        at play.api.http.HttpErrorHandlerExceptions$.throwableToUsefulException(HttpErrorHandler.scala:373)
        at play.api.http.HttpErrorHandlerExceptions.throwableToUsefulException(HttpErrorHandler.scala)
        at play.http.DefaultHttpErrorHandler.throwableToUsefulException(DefaultHttpErrorHandler.java:244)
        at play.http.DefaultHttpErrorHandler.onServerError(DefaultHttpErrorHandler.java:180)
        at controllers.ErrorHandler.onServerError(ErrorHandler.java:106)
        at play.core.j.JavaHttpErrorHandlerAdapter.onServerError(JavaHttpErrorHandlerAdapter.scala:32)
        at play.core.server.AkkaHttpServer$$anonfun$2.applyOrElse(AkkaHttpServer.scala:441)
        at play.core.server.AkkaHttpServer$$anonfun$2.applyOrElse(AkkaHttpServer.scala:433)
        at scala.concurrent.impl.Promise$Transformation.run(Promise.scala:490)
        at akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:63)
        at akka.dispatch.BatchingExecutor$BlockableBatch.$anonfun$run$1(BatchingExecutor.scala:100)
        at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.scala:18)
        at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:94)
        at akka.dispatch.BatchingExecutor$BlockableBatch.run(BatchingExecutor.scala:100)
        at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:49)
        at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(ForkJoinExecutorConfigurator.scala:48)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
Caused by: java.lang.RuntimeException: com.jayway.jsonpath.InvalidPathException: Filter: [?] can not be applied to primitives. Current context is:<PHONE_NUMBER>000
        at controllers.applicant.ApplicantProgramReviewController.lambda$review$6(ApplicantProgramReviewController.java:168)
        at java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
        at java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
        at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
        at java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
        at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
        at java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
        at play.core.j.HttpExecutionContext.$anonfun$execute$1(HttpExecutionContext.scala:64)
        ... 7 common frames omitted
Caused by: com.jayway.jsonpath.InvalidPathException: Filter: [?] can not be applied to primitives. Current context is:<PHONE_NUMBER>000
        at com.jayway.jsonpath.internal.path.PredicatePathToken.evaluate(PredicatePathToken.java:67)
        at com.jayway.jsonpath.internal.path.PathToken.handleObjectProperty(PathToken.java:90)
        at com.jayway.jsonpath.internal.path.PropertyPathToken.evaluate(PropertyPathToken.java:80)
        at com.jayway.jsonpath.internal.path.PathToken.handleObjectProperty(PathToken.java:90)
        at com.jayway.jsonpath.internal.path.PropertyPathToken.evaluate(PropertyPathToken.java:80)
        at com.jayway.jsonpath.internal.path.RootPathToken.evaluate(RootPathToken.java:66)
        at com.jayway.jsonpath.internal.path.CompiledPath.evaluate(CompiledPath.java:99)
        at com.jayway.jsonpath.internal.path.CompiledPath.evaluate(CompiledPath.java:107)
        at com.jayway.jsonpath.JsonPath.read(JsonPath.java:191)
        at com.jayway.jsonpath.internal.JsonContext.read(JsonContext.java:88)
        at com.jayway.jsonpath.internal.JsonContext.read(JsonContext.java:77)
        at com.jayway.jsonpath.internal.JsonContext.read(JsonContext.java:103)
        at services.CfJsonDocumentContext.evalPredicate(CfJsonDocumentContext.java:591)
        at services.applicant.predicate.PredicateEvaluator.evaluateLeafNode(PredicateEvaluator.java:55)
        at services.applicant.predicate.PredicateEvaluator.evaluate(PredicateEvaluator.java:35)
        at services.applicant.ReadOnlyApplicantProgramServiceImpl.evaluatePredicate(ReadOnlyApplicantProgramServiceImpl.java:444)
        at services.applicant.ReadOnlyApplicantProgramServiceImpl.isBlockEligible(ReadOnlyApplicantProgramServiceImpl.java:150)
        at services.applicant.ReadOnlyApplicantProgramServiceImpl.isQuestionEligibleInBlock(ReadOnlyApplicantProgramServiceImpl.java:339)
        at services.applicant.ReadOnlyApplicantProgramServiceImpl.lambda$isApplicationNotEligible$2(ReadOnlyApplicantProgramServiceImpl.java:130)
        at java.base/java.util.stream.MatchOps$1MatchSink.accept(MatchOps.java:90)

Update: This error is happening because of a question in the program with the admin id applicant_date_of_birth. This is the same key used in the json blob for applicant date of birth set by a TI when they add a client. The error occurs when applicant_date_of_birth is used to determine eligibility because the code tries to look up date on applicant_date_of_birth as set by the TI and errors out.
Seattle has 4 programs in production that use a question with admin id applicant_date_of_birth. Two of these are test programs and none of them use applicant_date_of_birth to determine eligibility so we shouldn't see this error in prod.
Next Steps:
@gwendolyngoetz is going to communicate the need to retire this question after these programs are done and not use applicant_date_of_birth as a question admin id going forward. I'm going to look into how to disallow applicant_date_of_birth as a question admin id programmatically.

Update: "Applicant date of birth" is one of the questions we seed when first setting up CiviForm and is intended to match the applicant_date_of_birth "well known path" used when a TI enters a birthday. This results in an error when a TI tries to apply to a program that contains this question, not just when there is an eligibility condition. This question is in use for many of Arkansas' programs, so we need a fix for the path and for the underlying data.
Next steps:
Do a data migration that changes all of the json blobs containing applicant_date_of_birth to the correct structure.
From:
{"applicant":{"applicant_date_of_birth":1696118400000}}

To:
{"applicant":{"applicant_date_of_birth":{"date":978307200000}}}

Also update the "well known path" linked above to be applicant_date_of_birth.date


Kha Build Tools Request

Hello Robert,
I am currently making a framework/game engine built upon Kha. In this I would like projects to be structured as such:
Project Folder
  SomeProjectDefinition.yml
  / assets
    art.jpg
  / src
    Code.hx
    AnotherFile.hx

I am planning on auto-generating project.kha, the problem is that hake doesn't swallow a structure like this. It expects project.kha to be in a folder that contains a Kha folder with all the tools in it.
Now this isn't a big problem for a single project, but if someone were to have to have X projects it would need X copies of Kha and tools. I believe it is not possible at the moment to have this externalised (I may be wrong?).
I read in the G+ group that you are working on khamake (which is a node.js alternative to hake if I am right?). I would like to request the enhancement to use the Kha buildtools from anywhere (this is probably also "required" if you are aiming for haxelib integration).

I think this is fully fixed by now. khamake can optionally take a kha= parameter that points to a Kha directory. If you run into any further problems with this, just hit me up again.


[BUG] - opening a saved maps does not show the saved layers

Bug Description
Loading a saved map shows the map itself, but the layer is not loaded in the layer list.
Also, clicking on a represented feature does not show the pop-up info box

Bug Reproduction
https://dev.undpgeohub.org/?style=196
Bug Impact
No response
Bug Screenshots
No response
Bug References
No response
Bug System Information
No response

I found it does not work since this commit.
https://github.com/UNDP-Data/geohub/commit/9b87d8e6d24f58ee1a00540ab5feac417c72e1c6#diff-2debaee1053cfd0ad577323527a22570a4d3e2fc2d596557f4a4a3e35b0a4df8


Suggestions of a subcommand shadowing valid input

Hello,
I have a problem with sub-commands when the app also expects a parameter
Rust Version
rustc 1.15.0 (10893a9a3 2017-01-19)
Affected Version of clap
clap 2.20.5
Bug Summary
In some cases, the suggestion feature will kick in and make the arguments parsing fail on an error even if the provided input is valid
Steps to Reproduce the issue
Here is a small app demonstrating the issue (basically a stripped down version of the example in the doc, the problem also happens with it)
#[macro_use]
extern crate clap;

fn main() {
    let matches = clap_app!(myapp =>
        (about: "Does awesome things")
        (@arg TEXT: +required "The text to be processed")
        (@subcommand test =>
            (about: "Run some tests")
        )
    ).get_matches();

    println!("text = {:?}, subcommand = {:?}", matches.value_of("TEXT"), matches.subcommand_name());
}

if we run this with these arguments
$ target/debug/clap-test foobar test

we get the expected output
text = Some("foobar"), subcommand = Some("test")

Now the problem arises when instead of foobar we pass hello
$ target/debug/clap-test hello test

hello is to close to the generated subcommand help
error: The subcommand 'hello' wasn't recognized
	Did you mean 'help'?

If you believe you received this message in error, try re-running with 'clap-test -- hello'

USAGE:
    clap-test <TEXT> [SUBCOMMAND]

For more information try --help

The problem disappears when deactivating the suggestion feature
Debug output
$ target/debug/clap-test hello test
DEBUG:clap:Parser::add_subcommand: term_w=None, name=test
DEBUG:clap:Parser::propogate_settings: self=myapp, g_settings=AppFlags(
    NEEDS_LONG_HELP | NEEDS_LONG_VERSION | NEEDS_SC_HELP | UTF8_NONE | COLOR_AUTO
)
DEBUG:clap:Parser::propogate_settings: sc=test, settings=AppFlags(
    NEEDS_LONG_HELP | NEEDS_LONG_VERSION | NEEDS_SC_HELP | UTF8_NONE | COLOR_AUTO
), g_settings=AppFlags(
    NEEDS_LONG_HELP | NEEDS_LONG_VERSION | NEEDS_SC_HELP | UTF8_NONE | COLOR_AUTO
)
DEBUG:clap:Parser::propogate_settings: self=test, g_settings=AppFlags(
    NEEDS_LONG_HELP | NEEDS_LONG_VERSION | NEEDS_SC_HELP | UTF8_NONE | COLOR_AUTO
)
DEBUG:clap:Parser::get_matches_with;
DEBUG:clap:Parser::create_help_and_version;
DEBUG:clap:Parser::create_help_and_version: Building --help
DEBUG:clap:Parser::create_help_and_version: Building --version
DEBUG:clap:Parser::create_help_and_version: Building help
DEBUG:clap:Parser::get_matches_with: Begin parsing '"hello"' ([104, 101, 108, 108, 111])
DEBUG:clap:Parser::is_new_arg: arg="hello", Needs Val of=None
DEBUG:clap:Parser::is_new_arg: Does arg allow leading hyphen...false
DEBUG:clap:Parser::is_new_arg: Starts new arg...Probable value
DEBUG:clap:Parser::is_new_arg: Starts new arg...false
DEBUG:clap:Parser::possible_subcommand: arg="hello"
DEBUG:clap:Parser::create_usage;
DEBUG:clap:Parser::create_usage_no_title;
DEBUG:clap:Parser::get_required_from: reqs=["TEXT"], extra=None
DEBUG:clap:Parser::get_required_from: args_in_groups=[]
DEBUG:clap:Parser::needs_flags_tag;
DEBUG:clap:Parser::needs_flags_tag:iter: f=hclap_help;
DEBUG:clap:Parser::needs_flags_tag:iter: f=vclap_version;
DEBUG:clap:Parser::needs_flags_tag: [FLAGS] not required
DEBUG:clap:Parser::color;
DEBUG:clap:Parser::color: Color setting...Auto
DEBUG:clap:Colorizer::error;
DEBUG:clap:is_a_tty: stderr=true
DEBUG:clap:Colorizer::warning;
DEBUG:clap:is_a_tty: stderr=true
DEBUG:clap:Colorizer::good;
DEBUG:clap:is_a_tty: stderr=true
DEBUG:clap:Colorizer::good;
DEBUG:clap:is_a_tty: stderr=true
DEBUG:clap:Colorizer::good;
DEBUG:clap:is_a_tty: stderr=true
error: The subcommand 'hello' wasn't recognized
	Did you mean 'help'?

If you believe you received this message in error, try re-running with 'clap-test -- hello'

USAGE:
    clap-test <TEXT> [SUBCOMMAND]

For more information try --help

Thanks for the details and taking the time to file this!
Depending on the design of the CLI you may be able to use AppSettings::ArgsNegateSubcommands which basically says, 'If you find a valid arg, no subcommand is possible so don't try to make suggestions."
Of course, this means an arg (not potentially matching a subcommand) must be used, which may not be possible depending on the design.
If by coincidence the problem only occurs with the help subcommand, you can disable it with AppSettings::DisableHelpSubcommand which still leaves --help and -h.
Unfortunately, there isn't much more that can be done, short of:

Disabling the suggestions feature as you found
Picking subcommand names that won't be similar to possible argument values

If you'd like to, I can take a look at your CLI as a whole and give a more specific suggestion, or perhaps find a valid workaround.

I our case, we ended up using a --text to pass the argument and remove any ambiguity, as the value of this argument is a free text for the user, so we cannot take chances an user would want to pass a value similar to one of our sub-commands. I mainly wrote the bug repport because that's a behaviour that exists in the doc example, and maybe it could be a good idea to modify it so that it doesn't have this problem (maybe by moving the INPUT arg to the subcommand )

I agree, I'll mark this as a doc issue! Thanks again for taking the time to file this!

I'm facing the same problem and none of the solution worked :/

@Freyskeyd can you give me more details. Each CLI is unique with different constraints and solutions.

@kbknapp
here's the cli.yml:
name: cli
version: "0.1"
author: Simon PAITRAULT<EMAIL_ADDRESS>
settings:
  - ArgRequiredElseHelp
  - DisableHelpSubcommand
  - ArgsNegateSubcommands

args:
  - track:
      help: environment + track
      required: true

subcommands:
  - deploy:
      about: Deploy command

If I use: cli depl.main deploy it suggest deploy command.

Answering question from https://github.com/clap-rs/clap/issues/1750

@kamilogorek Could you check that issue and try the options that are mentioned there?

As mentioned in the original issue, when InferSubcommands or AllowExternalSubcommands is used it works just fine. However, we cannot use them, as our CLI requires multiple subcommands, as well as arguments and it's too easy to miss incorrect input.

Hm ,weird name. I doubt it's easy since it's a bug in parsing algorithm.

I also encountered the same problem. As reported in https://github.com/wfxr/code-minimap/issues/6:
$ touch compiler
$ code-minimap compiler.rs
error: The subcommand 'compiler.rs' wasn't recognized
        Did you mean 'completion'?

If you believe you received this message in error, try re-running with 'code-minimap -- compiler.rs'

USAGE:
    code-minimap [OPTIONS] [FILE] [SUBCOMMAND]

For more information try --help

Add -- not works:
$ code-minimap -- compiler.rs
error: The subcommand 'compiler.rs' wasn't recognized
        Did you mean 'completion'?

If you believe you received this message in error, try re-running with 'code-minimap -- compiler.rs'

USAGE:
    code-minimap [OPTIONS] [FILE] [SUBCOMMAND]

For more information try --help

I tried to build app with AppSettings::ArgsNegateSubcommands but it still doesn't seem to work.
Is there any way to solve the problem without disable suggestion feature for now? Or this will be fixed in the future?

@ldm0 Would you like to take this one next?

Yep.


Fix missing sprintf in Schema.php

Wrong parameters for GraphQL\\Error\\InvariantViolation([string $message [, long $code [, Throwable $previous = NULL]]])

Coverage remained the same at 91.761% when pulling 66108bec84e27616bbeccbe6ae8d41a30e4adbf0 on ruudk:patch-1 into 87729589e084007030c0b9565fdbe4fd67b99d0e on webonyx:master.

Thanks!


GitHub web hook setup fails when using local.py config

While setting up GitHub on my development environment I ran into this error when selecting/saving repository during initial setup.
GitHubError: 422 Invalid request.
For 'properties/events', nil is not an array.
This is due to "events=None" in osf.io/website/addons/github/api.py  "def add_hook" Events must be an array/list. The following change fixed the issue.
# def add_hook(self, user, repo, name, config, events=None, active=True):
def add_hook(self, user, repo, name, config, events=['push'], active=True):

['push'] is the default for the github API. This could also be fixed by not passing "events" or "active" at all, letting them default to ['push'] and True.
Please let me know if you would like  PR for this.
Thanks, Tom

Hey @TomBaxter,
Looking at this, I think there are two issues.  First, we want to require the programmer who calls add_hook to specify which event they're creating a hook for.  We shouldn't be guessing for them.  So perhaps we should throw an error if events is None.  Secondly, did you note which bit of code was calling add_hook without providing an event list?  Wherever it is, it shouldn't be doing that.  The github addon was just refactored, so it's possible some code got changed or deleted on accident.  If you could track it down and provide a PR, that'd be awesome!  Thank you!
Cheers,
@felliott

Will do. Traveling with my wife today and tomorrow, but will work it as
soon as I'm back.
Thanks, Tom
On Feb 4, 2016 2:19 PM, "Fitz Elliott"<EMAIL_ADDRESS>wrote:

Hey @TomBaxter https://github.com/TomBaxter,
Looking at this, I think there are two issues. First, we want to require
the programmer who calls add_hook to specify which event they're creating
a hook for. We shouldn't be guessing for them. So perhaps we should throw
an error if events is None. Secondly, did you note which bit of code was
calling add_hook without providing an event list? Wherever it is, it
shouldn't be doing that. The github addon was just refactored, so it's
possible some code got changed or deleted on accident. If you could track
it down and provide a PR, that'd be awesome! Thank you!
Cheers,
@felliott https://github.com/felliott
—
Reply to this email directly or view it on GitHub
https://github.com/CenterForOpenScience/osf.io/issues/4974#issuecomment-180010266
.

Hey @TomBaxter,
Sorry, I just saw on our internal issue tracker that this has been identified and assigned.  I'll let them know about this ticket so they can close it when it gets merged.
Cheers,
@felliott

Nice! Thanks.
On Feb 4, 2016 3:14 PM, "Fitz Elliott"<EMAIL_ADDRESS>wrote:

Hey @TomBaxter https://github.com/TomBaxter,
Sorry, I just saw on our internal issue tracker that this has been
identified and assigned. I'll let them know about this ticket so they can
close it when it gets merged.
Cheers,
@felliott https://github.com/felliott
—
Reply to this email directly or view it on GitHub
https://github.com/CenterForOpenScience/osf.io/issues/4974#issuecomment-180027831
.

@felliott, the refactor hasn't gone in yet. There should only be one call that specifies the list of events; add_hook on the GitHubNodeSettings model. This doesn't accept events as a kwarg and passes in the event list (['push']) defined in addons/github/settings. I don't see anywhere else on develop or master calling the github/api method, which is called by the one on the model.

Confirmed with @TomBaxter, fixed when #4936 was merged into develop. This issue can be closed @sloria


Suggestion: issue label for set-top-box type platforms?

I know that my team is going to be supporting more and more smart TV / STB platforms in our future. It seems lots of other people are working in these environments too. Could we have an issue label for bugs from these platforms? This would cover any smart TV (Tizen, LG WebOS, Vizio, etc) as well set-top-boxes that support HTML5 environment (Enseo STB).

Sure, no problem.  I'll create a "TV/STB" label we can use for that.

Done!  https://github.com/google/shaka-player/issues?q=label%3ATV%2FSTB

Thank you!

De nada.


ci: build packages on release branches and tags

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 64.641%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
15826

Relevant Lines:
24483

💛  - Coveralls


[Regression] Command line options for flush_queue no longer working

The flush_queue management command no longer reports any command line options, and options like -w no longer work. Probably the health management command is similarly affected.

This is pushed to pypi now.


⚠ Samsung has degraded performance

In 4fc81ca, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2455 ms

Resolved: Samsung performance has improved in 879434c.


fix: [CDS-83545]: fix create agent when agent deleted outside of terraform

Describe your changes
Comment Triggers

PR Check triggers

Build: trigger build
Sub Category Field Check: trigger subcategoryfieldcheck
gitleaks: trigger gitleaks

trigger build

trigger build

Add test similar to TestAccResourcePipeline_DeleteUnderlyingResource to test out this scenario


Fix visible background line in intersections in screen-space reflections

master version of https://github.com/godotengine/godot/pull/56843.
Adjusting the step grading by one resolves the issue without affecting performance or introducing adverse artifacts.
Note: The above note about artifacts is currently not true due to a bug in the master SSR implementation that causes visible artifacts with the first step. This does not happen in 3.x and can be reproduced by setting Fade In to the Zero preset (right-click the value in the inspector).
This closes https://github.com/godotengine/godot/issues/50916.
Preview
Before

After

I don't think that https://github.com/godotengine/godot/issues/56845 is related. I would be fine merging this without addressing https://github.com/godotengine/godot/issues/56845 first

I don't think that #56845 is related. I would be fine merging this without addressing #56845 first

It's indeed not related, but this fix will make the artifacts more noticeable.

Thanks!


Which one is the exact threshold to define tracking failure

Hi, in the paper i see Failure is when L2 distance exceeds 50 pixels in the normalized 256 × 256 resolution. But in the code the sur_thres is assigned 16. So which one corresponds to the table in the paper?

Right, the paper used a threshold of 50. On thinking about how big 50 is within 256x256, I thought 16 might be more reasonable for the repo and future work. I think the right thing to do (as we did in the paper) is to re-run any baselines and re-measure things, to make sure everything is apples-to-apples.

Make sense. Thank you :)


github discussions

Hi Felix, perhaps it might be possible to open the discussions and perhaps wiki sections here on github.
I'd like to contribute some comments here, i.e. some possible advantages of this platform (leojs), and try to draw some attention this project :-D

@kghenderson  Will do!

Should be enabled now : https://github.com/boltex/leojs/discussions/45
Thanks again for this suggestion!


Error from Git Lens: cannot use extension any more

GitLens Version: v11.4.1
Git Version: 2.31.1.windows.1

VSCode Version: 1.56.1  e713fe9b05fc24facbec8f34fb1017133858842b  x64
OS Version: Windows 10 Pro 20H2 19042.985

Steps to Reproduce:

Install git lens
Try to commit some staged changes
This error shows up:

Command failed: C:\Program Files\Git\cmd\git.exe -c core.longpaths=true -c core.quotepath=false -c color.ui=false tag -l --format=%3cn%3e%(refname)%3c*r%3e%(*objectname)%3cr%3e%(objectname)%3cd%3e%(creatordate:iso8601)%3cad%3e%(authordate:iso8601)%3cs%3e%(subject) fatal: bad boolean config value 'null' for 'tag.forcesignannotated'

It happened all of a sudden: frankly, I cannot figure out what actions of mine caused the error, but now even if I uninstall/reinstall git lens, quitting/reloading/etc Visual Studio Code, I get his error. It used to work till yesterday.
I looked for the option tag.forcesignannotated in settings.json, but could not find anything. My experience with visual studio code is very little, sorry.
I have no problems in running git from the command prompt or using the built-in git commands: they work.

Hrm, that error is talking about your git config -- do you have anything like the following in your git config? (~/.gitconfig or in the .git/config file in your repo)
[tag]
forceSignAnnotated = true

Git seems to think you have an invalid value for that setting.


fix(ci): handle tests launch and run edge-cases

Motivation
Some tests are still failing with tee: 'standard output': Broken pipe, recently it has been more frequently with the sync-to-checkpoint test, but it could happen on other tests too.
Also, mounting errors are still happening, and we'd like to capture the dmesg when this happens at launch, for better debugging. Other options like set -x will also help debugging and replicating some commands locally.
Fixes #7564
Improves #7659
Solution

Use shell: /usr/bin/bash -exo pipefail {0} in GitHub jobs, for tests deployed to GCP
Temporarily disable "set -e" to handle the broken pipe error gracefully
Handle the exit code a bit better when reading from grep and docker wait
Use trap quotes correctly
Standardized --command quoting for GCP tests

Review

Confirm this is working with sync-to-checkpoint test.
Make the tests fail and confirm we're getting the required EXIT_STATUS code.

Reviewer Checklist

[ ] Will the PR name make sense to users?

[ ] Does it need extra CHANGELOG info? (new features, breaking changes, large changes)

[ ] Are the PR labels correct?
[ ] Does the code do what the ticket and PR says?

[ ] Does it change concurrent code, unsafe code, or consensus rules?

[ ] How do you know it works? Does it have tests?

The sync-to-checkpoint test won't run any more because we have a checkpoint disk now. So it won't run on PRs or in the scheduled jobs.
I think the tee error might be caused by set -o pipefail, or the input or output processes exiting early. Either way, replacing tee… with (tee … || true) should fix it. (That runs tee in a subshell and ignores its exit status.)
There might also be arguments we can pass to tee to change its exit status, like --mode=warn-nopipe:
https://www.man7.org/linux/man-pages/man1/tee.1.html

@teor2345 yeah, at least I was able to capture the errors before the checkpoint disk got fully build and the job started to get skipped.

@teor2345 yeah, at least I was able to capture the errors before the checkpoint disk got fully build and the job started to get skipped.

Let's see if the error happens on other jobs? If it doesn't then maybe we can lower the priority of this PR and ticket.

It's happening here too: https://github.com/ZcashFoundation/zebra/actions/runs/6450509996/job/17510016301#step:4:240

It might be worth trying tee --mode=warn-nopipe ... or (tee … || true) if you're looking for a quick fix.

It might be worth trying tee --mode=warn-nopipe ...

It looks like --mode=exit-nopipe doesn't work, because we need tee to exit when grep finds something, and it's not doing that here:
https://github.com/ZcashFoundation/zebra/actions/runs/6450645551/job/17510271960?pr=7690#step:4:291
That means all the other modes won't work either.
But (tee … || true) will definitely ignore the exit status.

This should be good to go

Unfortunately this PR failed in the merge queue due to issue #7659, so it might help to focus on fixing that issue first.

Yeah, I'll now focus on #7659

Yeah, I'll now focus on #7659

I've tried another way to un-block that issue in PR #7703: repeating the failing job until it works. It's not a long-term solution, but it would let us merge other PRs while we're fixing it.

Looks good to me, sync-to-checkpoint test passed here: ZcashFoundation/zebra/actions/runs/6455786703/job/17524400741

That's the sync-past-checkpoint test, this PR also needs a full sync to verify it works. @gustavovalverde did you want to run a full sync now, or wait until Friday?

@teor2345 last Friday it failed, so I triggered a new one here:
https://github.com/ZcashFoundation/zebra/actions/runs/6460865308

Running https://github.com/ZcashFoundation/zebra/actions/runs/6460865308 failed, as that's basically the only test not needing a cached state and thus the only one which was not tested in this PR 😞
It should be fixed now in:

#7709

I'm running a Full sync from that branch to confirm: https://github.com/ZcashFoundation/zebra/actions/runs/6461129131


Custom property type on model type

Which Category is your question related to?
API/GraphQL
What AWS Services are you utilizing?
AppSync, GraphQL Transform
Provide additional details e.g. code snippets
I'm trying to add a custom field type to a @model annotated GraphQL type like so:
enum NotificationMethod {
  ALL
  SMS
  EMAIL
}
type Settings {
  notifications: NotificationMethod
}
type User @model {
 settings: Settings
}

However, whenever I try and amplify push, I receive this error about the generated subscriptions:
.../src/graphql/subscriptions.ts: Field "settings" of type "Settings" must have a selection of subfields. Did you mean "settings { ... }"?
✔ Generated GraphQL operations successfully and saved at src/graphql

Oddly enough, the push succeeds and everything works as normal. Queries/mutations in the GraphQL console all work as expected. The generated src/graphql/subscriptions.ts file however is not selecting the appropriate Settings.notifications subfield for a response though, and therefore we're getting this error.
I'm assuming this type of nesting of types is probably solved by normalizing the data and separating the settings out into a Settings @model and then adding a @connection, however we'd like to keep these settings on the User.
What's the recommended way forward here?

@patrickeddy this is a bug in codegen. I will work on fixing this, but in the meantime you could fix this by increasing the maximum statement depth to 3. You can do this by running $ amplify codegen configure and setting Enter maximum statement depth [increase from default if your schema is deeply nested] to 3

@yuth thank you so much for the fast follow-up on this! Unfortunately even after setting the maximum statement depth to 3 or 4, I get the same error.


Support srcdoc attribute in iframe component.

Do you think it would be reasonable to add srcdoc attribute support to the iframe component? This would enable embedding  arbitrary html. The sandbox attribute might go along with this in order to enable scripts.
For context, I have been looking into doing some data visualisation in FastUI but this could also be useful for embedding reports, for example from MultiQC.
# Use it in FastUI like:
c.Iframe(srcdoc='
FastUI is neat
', src='https://pydantic.dev', width='100%', height=400),

sounds good to me, PR welcome.


Merge changelog changes back to master.

@brancz Same thing again. Once this is merged I will update the GitHub release notes.

lgtm