Empty strings are not considered null values

Bug
Empty strings does not trigger ValueErrors. If my attr is not optional why allow users to send an empty string to a field that is required and is a string?
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
             pydantic version: 1.5.1
            pydantic compiled: True
                 install path: /home/guiscaranse/.local/share/virtualenvs/api/lib/python3.7/site-packages/pydantic
               python version: 3.7.7 (default, May 30 2020, 15:17:46)  [GCC 7.5.0]
                     platform: Linux-5.3.0-53-generic-x86_64-with-debian-buster-sid
     optional deps. installed: ['typing-extensions', 'email-validator']

Example:
from pydantic import BaseModel
class test(BaseModel):
  a: str

test(a="")

This is not at error.  An empty string is a valid string.
You can use constr.

@samuelcolvin What if I want an empty string to trigger the default value without giving an error? Is there a way to do that?
This is common when dealing with frontend frameworks, they tend to send empty strings

Hello @mojimi
You could do something like this
from pydantic import BaseModel, validator

class Model(BaseModel):
    foo: str

    @validator('foo')
    def never_empty(cls, v: str) -> str:
        if not v:
            return 'pika is the best'  # the default value you want
        return v

Hope it helps

+1 seems like Pydantic should offer a way via e.g. constr to simply coerce "" to None.


multiprocess for input plugin "forward"

Hello,
first a quick overview of our Fluentd utilization:
we have 40 Apache front server producing 1tb log per day. Those logs are send to 2 fluentd relay then send to an Amazon Kinesis repo.
We noticed a performance bottleneck with a 5Mb/s. We our 40 HTTP nodes, we should be able to handle at least 40Mb/s.
We managed to reach good performances by using @type multiprocess with 20 nodes:
cat td-agent.conf
<source>
  @type multiprocess
  <process>
    cmdline -c /etc/td-agent/td-agent-child1.conf --log /var/log/td-agent/td-agentd_child1.log
    sleep_before_start 1s
    sleep_before_shutdown 5s
    log_level debug
  </process>
  <process>
    cmdline -c /etc/td-agent/td-agent-child2.conf --log /var/log/td-agent/td-agentd_child2.log
    sleep_before_start 2s
    sleep_before_shutdown 5s
    log_level debug
  </process>
  <process>
    cmdline -c /etc/td-agent/td-agent-child3.conf --log /var/log/td-agent/td-agentd_child3.log
    sleep_before_start 3s
    sleep_before_shutdown 5s
    log_level debug
  </process>
  <process>
    cmdline -c /etc/td-agent/td-agent-child4.conf --log /var/log/td-agent/td-agentd_child4.log
    sleep_before_start 4s
    sleep_before_shutdown 5s
    log_level debug
  </process>
  <process>
    cmdline -c /etc/td-agent/td-agent-child5.conf --log /var/log/td-agent/td-agentd_child5.log
    sleep_before_start 5s
    sleep_before_shutdown 5s
    log_level debug
  </process>
</source>

Each of the 5 childs handle 4 HTTP nodes.
But the configuration becomes quite messy.
The best solution for us to keep a maintanable configuration set would be an integrated input forward multi process.
Without this feature, Fluentd is not considered safe for my company to process our HTTP log stream. Kafka or a similar tool will be used instead.
Is multiprocess for forward plugin planned for the next release?
Thank you
Mathieu Perriere.

Is multiprocess for forward plugin planned for the next release?

This feature will be included in the v0.14 release, not v0.12 series.
v0.14 is now under development so we don't have stable release recently.

This is listed in v0.14 list.
https://github.com/fluent/fluentd/issues/829


Accessing outputOrientation needs to be done in main thread

What
This PR fixes UI being accessed from non main thread on iOS.
Changes
When self.outputOrientation is accessed it jumps to main queue for it.
Tested on
iPhone 8, iOS 14.4.1
Related issues

Relates to #887

Is just took comment in the code as fact. 😀  Not so familiar with AVCaptureSession. But I tried without the cameraQueue just throwing it all in main thread and it works so it might be better solution. Want me to update the PR with that?

Yup! 👍


System.Array.Copy(Int64) support

This issue tracks support for the Int64 overload of System.Array.Copy() method.

Pull request #3966 also implements this feature.

The pull request worked fine, so this feature can make it to Bridge 17.8.0!


HP GEN  10

Hey, do you know when the patch for the gen 10 can be there ? my fans are at 100% all the time the noise is little horrible..
thx u

Hi, no problem i think my problem are not the fans, the ilo speed management are enought i think, my main problem is this **** BMC chip who up to 80 90°, Maybe other can have this issue, i will try to put a radiator on it, like a intel default rad without the fan.
Thx u btw Alex


Membership streams not picking up TLs

There seems to be an issue that appeared in the last month or so where TLdex isn't picking up live TLs in membership streams.

If it's happening in chat, it can't because the chat is private to members. The TLer has to be using the TL client on-site.

That's the strange part, it was capturing until just recently. In one instance, I believe the TLer normally uses the client and sends to both TLdex and live chat.

Only happens when TLDex is used to translate mengen. Otherwise we don't pickup chat, i think.


[feature] Support parallel combine and disk spill for groupBy execution

When I read the source code Pinot's GroupByExecutor, I found out it lacks of the following features of Druid's GroupByV2Engine:

Spill to disk for merging buffer. Druid ParallelCombiner
Parallel combine when merging sorted aggregation result.  Druid will create a combining thread tree for local historical nodes.  Druid SpillingGrouper

  //        o         <- non-leaf node
  //     / / \ \      <- ICD = 4
  //  o   o   o   o   <- non-leaf nodes
  // / \ / \ / \ / \  <- LCD = 2
  // o o o o o o o o  <- leaf nodes

Reference: Druid GroupBy Tuning Guide
Druid seems to always sort the aggregate result by default when the Limit pushdown is not enabled as the tuning guide mentioned. I have a strong feeling that integrating DiskSpill feature allows Pinot to process large scale of data and resolve the issue of indeterministic result for groupBy without orderBy, i.e. https://github.com/apache/pinot/issues/11706. In addition, the NonLeaf stage in Multistage V2 can also adopts those two features for partitioned aggregation.
Raise this issue to solicit opinions from folks. If there's sufficient support, I will write a design doc for leaf stage group by execution.

What is the main benefits of this feature on group-by? In what cases it will improve the status-quo Can you be more specific?

disk spill: currently the num of group limit is used to avoid OOM and the return result is not accurate. Enable disk spill can get deterministic result. The Apache Druid / Doris and Velox already support disk based group by.
parallel combine: speed up the combine process
@chenboat

This is a good feature to have. Would love to review the design proposal. it will be good to write a stand-alone algorithm that allows us to leverage it in multiple places/operators

I have read Druid's related source code and will share details in recent days.

I did' have bandwidth to fully interpret the Druid groupBy algorithm. But here is the headline version: let say there are 8 workers. The segments are distributed across 8 workers. Each worker has a local hash table which use linear probing to resolve hash collision. Each worker is in charge of storing aggregated result for one partition. If a worker find out the aggregated key doesn't belong to the local partition, the worker would insert the aggregated row to other worker's hash table. If any one local hash table doesn't trigger the disk spilled condition, then there's no need to merge partition. However, if any of table trigger the disk spilled condition, then each worker would not distribute the aggregated row anymore. Each worker just do pre-aggregation internally. In the combination phase, the result would be merged on the fly, combining the result of each hash table's in-memory and on-disk result.
The DuckDB's has similar idea even though there are nuances: https://duckdb.org/2024/03/29/external-aggregation.html Each thread do pre-aggregation without distributing result at all and then combine result. They also user linear probing with salt. linear probing is more disk friendly. To support resize efficiently, they implement a two-part aggregate hash table https://duckdb.org/2022/03/07/aggregate-hashtable
The Pinot groupBy currently doesn't support external aggregation and all threads write into a in-memory single concurrent hash map.
The bustub implements a disk based hash table and use latch crabbing to increase concurrency. https://15445.courses.cs.cmu.edu/spring2024/project2/
@chenboat For your question, I would say achieve low-memory usage purpose for groupby. To be general, each operator can support disk based mode, e.g., external sorting.

Personally, I prefer DuckDB's approach. Each worker has its own disk-based linear probing hash table to do pre-aggregation without interacting with other workers. And then do combination.

https://www.databend.com/blog/2024-04-12-towards-efficient-distributed-group-aggregation.md/
dataend execution is incredibly fast. they follow duckdb

Discuss with Jackie and he suggested to single out parallel aggregation from the disk spilled feature.

The doc is in progress: https://docs.google.com/document/d/1GViPFE-wEpz2LIH79a1epr0u1AGcZ4QZzcWIWW77AlM/edit?usp=sharing


feat(client): provide option for disabling console warn messages

add noWarn client parameter
resolves #319

This PR contains a:

[ ] bugfix
[x] new feature
[ ] code refactor
[ ] test update
[ ] typo fix
[ ] metadata update

Motivation / Use-Case
Add support for disabling console.warn messages on the client.
Resolves #319
Breaking Changes

Additional Info

Unfortunately, the internal warn variable is poorly named, setting it to true will also hide error logging.

Ah, ok didn't realize that.  I'll take a closer look.

@jgraniero Are you still working on this? We have the exact same use case you originally reported. Thank you for trying to add warningsFilter support ❤

Yea, been super busy so haven't had the time to revisit this yet, but I'm trying!

No pressure. Thank you for looking into this.


Shortcut for foreign key definitions

instead of
table.integer('booking_id').unsigned().references('booking.id')

maybe it would make sense to do
table.reference('booking', 'id', 'booking_id')

the last two args even can be defaulted to the values. If this is a good idea, I might be creating a pull request.
BTW: Awesome stuf you build here and with bookshelf! The ORM/Query-Builder I always wanted ;)

There hasn't been much support for this. Closing for  now (cleaning up / tagging old issues).


VLAZ: Watch mistyseveri.com

VLAZ requests the watch of the watch_keyword mistyseveri\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

mistyseveri\.com has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


API deprecate -p shortcut in favor of -o for Objective

fixes #225
I have an issue, the warnings are captured even with BENCHOPT_DEBUG=1, I think they should not because the user won't be notified of the deprecation.
It remains to adapt the test if you agree with this @tomMoral @agramfort

Codecov Report

Merging #281 (98b2c4d) into main (4860622) will increase coverage by 0.06%.
The diff coverage is 85.71%.

@@            Coverage Diff             @@
##             main     #281      +/-   ##
==========================================
+ Coverage   60.80%   60.86%   +0.06%
==========================================
  Files          41       41
  Lines        2202     2208       +6
  Branches      401      402       +1
==========================================
+ Hits         1339     1344       +5
  Misses        766      766
- Partials       97       98       +1

maybe a call to catch_warnings somewhere?

@tomMoral do you know where this is coming from ? If we call warnings.resetwarnings() of warnings.setfilter("always") before warnings.warn, then the warnings are shown (in addition it shows useful DeprecationWarning for stping_strategy).
So something is catching the warnings somewhere ?

I added the whatsnew entry, the doc is OK because it's generated from the python click file and there are no examples where we filter objectives


Little tutorial in the app?

Modern apps often have a quick tutorial that points out basic UI elements and gives users hints on what to do as they explore. Would be cool to have this too.
Probably needs a simple standalone framework that all JavaFX users can benefit from. Dimming out parts of the UI to highlight particular areas should be easily achieved using clipping rects and the scene graph, so it'd be cool if there was a library that let us do something like:
UITutorials.teachNode(button, "Click here to access app settings")
and then the rest of the UI fades or blurs out, the button is shown in a spotlight and an arrow/text appears.

Actually I added a couple of tutorial bubbles that appear if you try and pledge without any bitcoins in the app, as I suspect that's the most common error people will make when exploring.


Order of argument type checks is unclear.

When argument types are dynamically checked for strong mode, is the order of the checks defined?
Or can they be checked in any order?
For example, consider this code:
abstract class C<T> {
  void foo(Object x, T y);
}

class D<S, T> extends C<T> {
  void foo(covariant S x, T y) {
    // ...
  }
}

main() {
  C<Object> c = new D<int, int>();
  c.foo("error", "error");
}

Is is a valid behavior for this program to throw an exception for the incorrect type of "y" (having been
checked before "x")?

cc @lrhn @eernstg I see no reason to tie this down in the spec.  I would prefer us to explicitly allow any order of checks so long as no code is observed to have run in between the checks.

For context, this could facilitate an optimization we're currently evaluating in the VM wherein the code D.foo above would have two entry-points, one which would skip the check against y. In this scenario, would like to order the code for checking y before checking x so that the entry-point which skips y can just jump to the check for x directly.

I agree that there is no advantage, and some disadvantage, in specifying which error is thrown first.
It is an error during the parameter binding of the invocation if all arguments are not assignable to the corresponding formal (or if there are arguments with no corresponding formal, in the case of dynamic invocations).

I think the order should be specified.
For dart2js we will likely want to keep the order consistent so that errors in production are repeatable as the program evolves. It would be a disadvantage to have the 'same' error clustered into multiple groups because each push of the program used a different order and reported a different TypeError. Developers need to be able to tell that the most recent push fixed the problem, not just caused it to express differently.
Samir, if I understand, you say that an unconstrained order permits you to reorder checks to enable better tail-merging of the check sequence. Can you quantify the benefit?

For dart2js we will likely want to keep the order consistent so that errors in production are repeatable

This is consistent with the order being unspecified.

@rakudrama: I can't quantify the benefit yet, since we're still working on the optimization. However, I understand that we're releasing Dart 2 tomorrow, and making it unspecified after it is already specified would be a breaking change.

We have previously preferred specifying the execution order for many parts of the language (typically: following the textual order), based on the argument that this is good for correctness and predictability. I believe that we have also explicitly noted that this may prevent certain optimizations (exactly like the one which is mentioned here).
Following that rationale I'd tend to prefer a specified and deterministic ordering, based on the textual order of the declarations.
However, I do acknowledge that this is a corner case and it's unlikely to cause many bugs, so I won't push for it if there's a strong push for leaving it unspecified.

We are already performing optimizations in the AOT where we split function prologue into two parts complementing each other: one of the parts contains just covariant checks, while the other becomes a separate forwarding stub and contains all of the checks and is used when arriving from contexts that we consider dynamic.
Requiring the specific order of checks would invalidate this optimization in the current form: we would need the forwarder to contain all the checks meaning an potential code size increase.
In general I would favor leaving this unspecified because it simplifies implementations and gives them a bit of flexibility.
The behavioral difference can only be observed on incorrect programs

OK, we may then want to make it explicit in the specification that this particular kind of ordering is unspecified. Are we only talking about the ordering among dynamic type checks on parameters of a function invocation, or does it involve the ordering of dynamic type checks relative to other actions as well?

Only between type checks themselves. We can still specify that they happen before any other code in the body is executed.

Can we put an upper bound on the non-determinism of an invocation of a function where more than one actual argument violates the actual value of the type annotation of the corresponding formal parameter?
Maybe: Such an invocation will incur a dynamic error which may be based on any one among the actual arguments violating the type annotation.
I wouldn't be surprised if it were possible to create a typing situation where the exact same objects may be passed but the choice of culprit will be different, because the associated static typing situation is different.
On the other hand, we may be able to promise that there is no non-determinism in the side effects associated with the evaluation of the actual argument expressions (because they are all evaluated before these dynamic type checks take place).
Or what do you think we can promise?

There is no breaking change in making this decision. The specification is clear-ish (still written in Dart 1 terms) - it is a run-time error if you cannot bind any of the arguments to its corresponding formal because of non-assignability. The specification does not say which error, nor does it say which order to check.
This only applies to dynamic invocations and covariant arguments (declared or from generics), since all other parameter passing cases are guaranteed to be successful by the static type system.
So, the only difference this might make is to cause a different of two or more simultaneous errors  to be reported. All the errors must be fixed anyway, and fixing one will expose the other.
Over-specifying error conditions is a great way to introduce unnecessary overhead. I'd prefer not to do that.


minetest: update 0.4.4 -> 0.4.12

Successfully tested. Depends on #7863

Thank you! I fixed the nitpick and merged this PR manually

Oh, okay. I'll try to remember that.


doom-load-envvars-file does not set environment but rather only defaults for subprocesses to inherit

What did you expect to happen?
(doom-load-envvars-file "~/.doom.d/env") sets all environment variables declared in "~/.doom.d/env", adding and updating variables in the environment of the running emacs process as needed.
To solve this issue, the implementation of doom-load-envvars-file needs to be changed to avoid only setq-default process-environment but rather call the setenv function for each variable defined in the environment file. load-env-vars.el implements the required functionality.
What actually happened?
(doom-load-envvars-file "~/.doom.d/env") sets process-environment variable, specifying defaults for subprocesses to inherit but does not change the environment variables of the running emacs process.
Describe your attempts to resolve the issue
For the variables important to me, I manually called setenv
(setenv "TZ" "America/New_York")

Steps to reproduce

Create a new environment configuration doom env -o ~/.doom.d/myenv. Modify the TZ variable in the new myenv to a value different to your default TZ. For example, if echo $TZ in your shell returns UTC, set TZ to America/New_York in myenv.
Modify ~/.doom.d/config.el to (doom-load-envvars-file "~/.doom.d/myenv")
Start Emacs
Run M-x doom/info and note the time shown i based on TZ in your shell environment, not based on the TZ specified in the ~/.doom.d/myenv.

System Information
https://pastebin.com/kQswzLhX

As of 9dad269 this issue should now be resolved. This happens because TZ is the one exception to this rule. It is a special case in setenv and causes Emacs to call set-time-zone-rule for it. For any other envvar, doom-load-envvars-file is sufficient.
Anyhow, I've modified doom-load-envvars-file to properly process TZ if it is present. Let me know if that isn't the case and I'll reopen it. Thanks for bringing it to my attention!


Apex 3 Keyboard locks up when running apexctl, have to reseat cable.

The title says it all:
https://youtu.be/W81LvtMsQ0w

Thanks for the report, I guess I learned that I need to be careful when publishing code for devices I can't test.
Unfortunately, the very fact that I don't have an Apex 3 to test with means I can't realistically support it. I have no idea what's going on, and no clue how to fix it, and nobody to help me figure it out.
I've moved the Apex 3 and Apex M800 support behind an opt-in make flag, so you can try playing with it if you want to, while hopefully saving others from this annoying situation.

I could always make a donation. I got the keyboard for only like 50 USD

I would very much appreciate that, but I should mention I don't live in the United States, so we'll have to work out shipping.

@AstroSnail any development toward the support of Apex 3?
Given that it locks up the keyboard, I am not too keen on trying it :)


Remove weird animation when changing present theme

The animation when changing the theme is very weird and It will bring confusion to the user when changing the theme, i would consider removing it

Thanks 🙏, it was really annoying bug


[$1000] Selecting a chat message and pressing any key focus the message instead of switching the focus to the composer.

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

Action Performed:

Go to any chats
Click on any message
Press any letter.

Expected Result:
Character is typed in the message composer
Actual Result:
Message gets focused instead
Workaround:
unknown
Platforms:

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

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

Version Number: 1.2.87-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/226144582-9575020a-f3c2-48e3-a7a4-82c2f47cfcdb.mp4
https://user-images.githubusercontent.com/43996225/226144598-adbaa189-7e4c-41da-94a3-50736a43c410.mp4
Expensify/Expensify Issue URL:
Issue reported by: @pecanoro
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1679075457783789
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0108a1ba7c41369017
Upwork Job ID:<PHONE_NUMBER>704986624
Last Price Increase: 2023-04-06

Triggered auto assignment to @sophiepintoraetz (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

Tomorrow

Hopefully have some time today - now that I'm recovering!

Triggered auto assignment to @PauloGasparSv (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

Making this external!

Job added to Upwork: https://www.upwork.com/jobs/~0108a1ba7c41369017

Current assignee @sophiepintoraetz is eligible for the External assigner, not assigning anyone new.

Triggered auto assignment to Contributor-plus team member for initial proposal review - @rushatgabhane (External)

Current assignee @PauloGasparSv is eligible for the External assigner, not assigning anyone new.

Proposal
Please re-state the problem that we are trying to solve in this issue.
When clicking on a chat message and click on any character, the message gets focused and the composer is not.
What is the root cause of that problem?
The ReportActionItem is focusable, and we don't have any keydown listener to focus the composer, so the ReportActionItem will get focused.
What changes do you think we should make in order to solve the problem?

We should make the behavior consistent with Slack, by automatically focusing on the Composer if we press on regular characters like a, b, c, d (not non-character keys like Enter, Shift) when we're not typing on any input or textarea.
This can be done by:

Add a new keypressListener  listener method to the ReportActionCompose here

keypressListener(e) {
        if (this.state.isFocused) return;

        // if the key pressed is non-character keys like Enter, Shift, ... do not focus
        if (e.key.length > 1) return;

        // if we're typing on another input/text area, do not focus
        if (e.target.nodeName === 'INPUT' || e.target.nodeName === 'TEXTAREA') return;

        // Otherwise, focus the composer and update the comment with the pressed key
        this.focus();
        this.updateComment(`${this.state.value}${e.key}`, true);
    }

and bind it in the constructor

In componentDidMount here add document.addEventListener('keydown', this.keypressListener);
(We shouldn't use keypress because it's a deprecated method, also it will still capture keys like Enter so there's not much difference from keydown in our use case)

Add document.removeEventListener('keydown', this.keypressListener); to componentWillUnmount.

What alternative solutions did you explore? (Optional)

If we want to be more precise with the non-character key check ( if (e.key.length > 1) return;) we can go with a regex as well.
We need to decide what we want to do for Message edit case since there could be multiple edit messages opening at once. Slack only auto focuses on the main composer, not the edit composer. For that the above solution is enough.

Not overdue!

@getusha @tienifr your solutions are code diffs. Please explain your solution in plain english

@PauloGasparSv @sophiepintoraetz I'm curious about what exactly we want here
Precondition - composer is not focused.

Pressing any key will focus the composer
Or, pressing any key will focus the composer and insert it in the composer as well

Asked @pecanoro on slack to post a problem solution because I believe this is not a bug, but a feature request.

Asked @pecanoro on slack to post a problem solution because I believe this is not a bug, but a feature request.

Thanks for that @rushatgabhane let's wait for that response

Or, pressing any key will focus the composer and insert it in the composer as well

That's a great question, I don't think that's defined here. I see you asked that on slack too : )
IMO that is the intent and we should only do it for alphanumeric keys.

Commented on the slack thread but let's not draw this process out unnecessarily with a P/S as this is a bug not a feature request.

@PauloGasparSv @rushatgabhane @sophiepintoraetz this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

but let's not draw this process out unnecessarily with a P/S

Okayy sounds good.
To move this forward, let's just go with (2) unless someone disagrees

pressing any key will focus the composer and insert it in the composer as well.

@getusha @tienifr the solutions are code diffs. We don't accept that now. Please update the proposals by explaining the solution in plain english. Thanks 🙇

@rushatgabhane I've updated the proposal to avoid code diffs, thanks!

Hey @rushatgabhane  I like @tienifr's updated proposal! Can you take a look at it (curious on your feedback)?

on it

@PauloGasparSv I recommend @tienifr's proposal
Pressing any key will focus the composer and insert it in the composer wherever the previous selection was placed.

@getusha's proposal appends the value to composer instead of placing it wherever the previous selection (cursor) was

📣 @tienifr You have been assigned to this job by @PauloGasparSv!
Please apply to this job in Upwork and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑💻
Keep in mind: Code of Conduct | Contributing 📖

@PauloGasparSv we have to undo price to 1k
sorry for delay!

Nice catch @rushatgabhane! The approved proposal predates the change so let me rollback to $1000
cc @sophiepintoraetz

Upwork job price has been updated to $1000

@rushatgabhane  The PR is ready for review: https://github.com/Expensify/App/pull/17138

Hey @rushatgabhane, will you be able to review the PR? 🙏

@rushatgabhane Many thank for your fix

Regression Test Proposal
Bug: Selecting a chat message and pressing any key focus the message instead of switching the focus to the composer
Proposed Test Steps:

Go to any chats
Click on any message
Press any character keys like a,b,c,d (not non-character keys like Enter, Shift)
Verify that the composer is focused again and the above character is entered in the composer
Open Search Page and blur the input on the search page
Press any character keys like a,b,c,d (not non-character keys like Enter, Shift)
Verify that these characters aren't entered in the main composer
Open Emoji Picker and blur the input on the search
Press any character keys like a,b,c,d (not non-character keys like Enter, Shift)
Verify that these characters aren't entered in the main composer

Do we :+1: or :-1:

I think we caused another regression reported by @situchan  here! In the first P.R. we caught a bug and fixed it where the composer box and the emoji search input would receive keyboard input at the same time.
This bug is similar, clicking in the "Change Default Skin Tone" is causing that to happen again for some reason.
I'm investigating here.

I think we caused another regression reported by @situchan here!

GH created: https://github.com/Expensify/App/issues/17413

Another related to issue: https://github.com/Expensify/App/issues/17411

Another related to issue: https://github.com/Expensify/App/issues/17411

That one was discussed here and here and I think it should be treated as a separate issue : )

Seems regression when in RHN opened popover closes, it focuses the composer even though the RHN is still open.
https://user-images.githubusercontent.com/14358475/232117268-650f1c70-37e5-470b-9227-0ce1250cdf74.mov

I think we should revert these two, there too many regressions caused by these changes:

https://github.com/Expensify/App/pull/17360
https://github.com/Expensify/App/pull/17138

And get rid of https://github.com/Expensify/App/pull/17428 or maybe use it to remove the change if reverting both P.R.'s is a challenge.

⚠ Looks like this issue was linked to a Deploy Blocker here
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

@PauloGasparSv @rushatgabhane  Hi sorry for the trouble here, PR to revert is ready.

@tienifr or @rushatgabhane - can you summarise the number of regressions attached to the PR, please?

Reviewing label has been removed, please complete the "BugZero Checklist".

The solution for this issue has been :rocket: deployed to production :rocket: in version 1.3.0-2 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

https://github.com/Expensify/App/pull/17138
https://github.com/Expensify/App/pull/17360

If no regressions arise, payment will be issued on 2023-04-24. :confetti_ball:
After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

[ ] External issue reporter
[ ] Contributor that fixed the issue
[ ] Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

Merged PR within 3 business days of assignment - 50% bonus
Merged PR more than 9 business days after assignment - 50% penalty

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

[ ] [@rushatgabhane / @PauloGasparSv] The PR that introduced the bug has been identified. Link to the PR:
[ ] [@rushatgabhane / @PauloGasparSv] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
[ ] [@rushatgabhane / @PauloGasparSv] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
[ ] [@sophiepintoraetz] Determine if we should create a regression test for this bug.
[ ] [@rushatgabhane] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
[ ] [@sophiepintoraetz] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

So just to be clear here do we have a solution in place to fix the original issue?

we have 2 regression bugs, I am doing on it

Regression Bugs
There are 2 regression bugs here:

This issue

RCA: Because in the previous PR, we only check the emoji picker is open in the composer. There are other places in reportScreen that also trigger to open emojiPicker
Solution: We should create a new field in ONYX to keep track of the state of the emoji picker (open or closed) and then use this field to check whether we should listen key-down and focus on the composer. I just created a new PR with all changes of PR's code change reverted and also apply the above solution. So both issues here and here will be resolved

This issue

RCA: When the second popover modal is closed, it is setting the isVisible of modal in ONYX to false, while the parent popover is still opened -> wrong condition
Solution 1:

Add a new key in Onyx that stores the number of modal being opened: OPENING_MODAL_COUNT: openingModalCount
Inside function setModalVisibility() in Modal.js, add check conditions to update ONYXKEYS.OPENING_MODAL_COUNT and ONYXKEYS.MODAL respectively

Solution 2:

Add shouldSetModalVisibility={false} in the Modal that has level > 1 (not the first popover)

Cc: @rushatgabhane @sophiepintoraetz @PauloGasparSv

@rushatgabhane @PauloGasparSv @sophiepintoraetz

When the second popover modal is closed, it is setting the isVisible of modal in ONYX to false, while the parent popover is still opened -> wrong condition

I think this bug doesn't come from my PR so should we handle it in other issue?

@rushatgabhane @PauloGasparSv Here is my new PR: https://github.com/Expensify/App/pull/17649. It's the combination of https://github.com/Expensify/App/pull/17138 and https://github.com/Expensify/App/pull/17360
Just one minor update: I want to add new condition EmojiPickerAction.emojiPickerRef.current.state.isEmojiPickerVisible to prevent key press event when the emoji picker is open. But the isVisible of modal in OnYX doesn't work as expect as I mentioned above, I think we can fix it on other issue. What do you think?
I'm really sorry for this inconvenience. I'll try my best to resolve this issue ASAP. Thanks  🚀 🚀 🚀

Reviewing label has been removed, please complete the "BugZero Checklist".

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

[ ] [@rushatgabhane] The PR that introduced the bug has been identified. Link to the PR:
[ ] [@rushatgabhane] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
[ ] [@rushatgabhane] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
[ ] [@sophiepintoraetz] Determine if we should create a regression test for this bug.
[ ] [@rushatgabhane] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
[ ] [@sophiepintoraetz] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

@PauloGasparSv - what's needed here to close out this issue? Are you able to comment on the PR?

I've actually also stumbled across this issue here https://github.com/Expensify/App/issues/15992 whilst being assigned to other issues - so I wonder if we fold it into there as well?

Hey @sophiepintoraetz sorry for the delay here, was focused on N6.9!
Both me and @rushatgabhane feel like we shouldn't implement the feature because of all the edge cases and  regressions it can cause so I started a slack thread to discuss if we should implement this or not (and how to prevent regressions if we decide to implement it).

Thanks for starting that conversation, @PauloGasparSv! If I'm reading that right, are we agreeing not to do it?
@rushatgabhane looks like I owe you an apology - perhaps a P/S would have prevented some of the downstream issues we faced!

If I'm reading that right, are we agreeing not to do it?

Coming from the thread we agreed that:

We shouldn't dismiss this only because of regressions and bugs
It's ok if we don't do it for another reason but since WhatsApp and Slack have this feature that's a reason to implement.

IMO since our only concerns were regressions we should try to implement this again and update the Test/QA steps of the P.R so we test all flows that created regressions last time.
I also think it's a good idea to ask more people to review the P.R. before merging (it maybe by assigning puller bear again).
Does that sound good? cc @sophiepintoraetz @rushatgabhane @tienifr

Got it! Yes, I think we seek more reviews on the PR and take a more considered approach when building the PR 🙏

@mallenexpensify - I'm about to go OOO for the week so reassigning. There's been a few regressions so I don't think this issue will be eligible for a bonus payment should it come to that while I'm away (possibly a penalty), as Tienfr as assigned on Apr 6 and the PR is yet to merge. We are waiting on @rushatgabhane to review @tienifr's PR - it's been sitting for a week so have bumped Rushat in Slack.

@rushatgabhane please treat this as a priority, removed Awaiting Payment and Reviewing so it'll go over due and help light a 🔥

P.R. still in review!

P.R. still in review, latest updates here

Not overdue, we are still in progress and discussing a solution for this bug in the P.R.

Thanks @mallenexpensify for looking after it! I'll take this back now that I'm in office but def let me know if you'd like to stay assigned.

How are we tracking here, @PauloGasparSv ?

How are we tracking here, @PauloGasparSv ?

There were no updates this past 2 days, we are still having this bug.
I could not help with the bug yet but will stop do to so ASAP. Also bumped the contributors in case they have an update here

@PauloGasparSv @tienifr @rushatgabhane - can you please summarise the bugs/issues that you are stuck on and we'll take it to slack for suggestions.
Alternatively, we can look at assigning an agency to push this along further as well for ideas.

Well, that didn't work! Asking internally if another C+ can take this over.

I am OOO for the next week (back on 20 Jun) so thank you @mallenexpensify for looking after this. This issue has been moving slowly and possibly needs some help with the external agencies. The contributor/C+ and Paulo have been attempting to resolve the bugs in the PR but it's been a minute since the assignment.
We've had a new C+ that might help with the review but my plan was to drop it into the external slack rooms if we didn't get movement this week.

Enjoy your week off @sophiepintoraetz .  checking on here
Seems like a private #agency-issues channel could be a good idea

@tienifr
Can you give a summary of what happened on the issue, what's the reason this PR took this much time? Do we have anything unresolved here on the PR?
And I see there is some of the PR that has been inactive for almost the last 2 - 3 weeks. Daily updates are necessary unless even you are waiting for any input from CME/CPlus then bump them daily. Also if there is no response after multiple bumps. then please tag a BZ, so they can help the issue move forward, thanks!

Yeah, I agree!

Also agree @mallenexpensify!

Hey :wave: I’m Robert Kozik from Software Mansion, an expert agency, and I would like to help close this issue out. I see that a PR by @tienifr is already posted, so here we are talking about closing out this one, not coming up with new?

@tienifr can you please accept the job and reply here once you have?
https://www.upwork.com/jobs/~015d2f9b2b3e902298
@robertKozik I assigned to you, thinking you'd propose a solution. Are you thinking something different?

Sure, let me familiarise with whole issue and I'll propose something. The proposal used in the PR looks promising though, if I would came up with the way of detecting modal open.

Hi! I've checked the issue to get some context and I think it will be ok to stick to the way proposed by @tienifr. Personally I'm not the fan of the document-scoped listeners, but in this case it's understandable. I'm thinking about changing the implementation though as keyDownAction can be under the libs directory.
As I saw the main issue with this approach is how to determine whether or not composer is covered or not. I'm thinking about using the new navigation changes and base it on the route. As I checked, every open of RHN changes the url  i.e appends /settings to the report url. If we would check it, we will be sure that composer is not covered when path consist only of /r/<reportID> nothing else.
I need only to double check the assumptions about the RHN path case, if it's ok it should resolve the problem with the proposal and I'll document/implement it.

Hi! As for today I checked whether my idea with checking the url path is correct and it turned out better than I was thinking, with only 3 checkes it's possible to determine whether composer is covered or not (check the route, state of the popover menu and state of the emojiPickerPopover). I've created some rough implementation and checked the regressions which were listed inside the closed PR (link) and it looks like it already ticks all the boxes except the copy&paste one, which I wasn't aware of earlier.
All in all, I think that tomorrow I'll post PR for this.

I let myself write the proposal for this one, as the copy&paste function exceeds over the currently proposed implementation.
Proposal
Please re-state the problem that we are trying to solve in this issue.
In order to access the composer it needs to be focused.
What is the root cause of that problem?
After loosing focus on the composer it is not possible to access it again by keyboard.
What changes do you think we should make in order to solve the problem?

Handling key presses
This will go in line with @tienifr proposal with few tweaks.
The state of the composer, whether it's covered or not, will be calculated in the new function: checkComposerVisibility. The function will calculate this state based on:

current path with help of ROUTES.parseReportRouteParams (if reportID is not emptyString and isSubReportPage is false),
state of the EmojiPicker — here will be implemented new function isEmojiPickerVisible inside EmojiPickerAction.js file,
state of the + popover — its accessible via this.state.isMenuVisible.

In the libs/KeyboardShortcut directory there will be new folder KeyDownPressListener (with different implementation for web and native) which will will manage document-scoped keydown listener. The listener will be added to the document when the composer is visible and removed when it's not (handle by componentDidMount and componentWillUnmount lifecycle methods).
Callback function for the listener will be handleKeyDown function inside ReportActionCompose.js file. This function will be responsible for handling key presses. It will be implemented in the following way:

if the composer is not visible (based on checkComposerVisibility), it will do nothing,
if the composer is visible, it will check if the pressed key is alphanumeric or not. If it's not, it will do nothing.
if the pressed key is alphanumeric, it will check if we are not typing in the another input (f.e. search input). If we are, it will do nothing.
if the pressed key is alphanumeric and we are not typing in the another input, it will call this.replaceSelectionWithText function (this is the function that is responsible for inserting text into the composer) with the pressed key as an argument.

Handling special actions f.e. copy&paste
Copy&paste cannot be handled inside ReportActionCompose.js file because it's not possible to parse the photos and text without duplicating the code from Composer/index.js. Because of that, the paste event will be handled inside Composer/index.js file. It will require to alter current implementation of listener for paste event. For now listener is hooked to TextInput component, but it will be moved to the document. In order to restrict this listener, same as keydown listener, the visibility of the composer will be passed to it from ReportActionCompose component. With this change, the paste event will be handled only when the composer is visible or focused (the check will be done inside handlePaste function in Composer/index.js file).
What alternative solutions did you explore? (Optional)

For copy&paste I was considering to not change the textInput listener, but rather create the new document-scoped one along side. this document-scoped listener would be added or removed based on the current composer visibility. The problem with this solution is that it would require to add additional listener (we have many of them already). Moreover it would be harder to maintain, as the listener had to be removed on the propsUpdate.

@Santhosh-Sellavel , can you please review the proposal above?

@robertKozik So far looks good to me, let's see it in action!

Waiting for PR,  bump @robertKozik!

Actually I was just posting PR 😃

Not overdue, https://github.com/Expensify/App/pull/21583 is up and under review

Review in progress

That's for sure regression from this PR. I'm on it to find fix for it

@Santhosh-Sellavel can you complete the Checklist please? I see you are raising requests through NewDot as well, so can you fire a payment through for $2000? thank you!

Please hold on from any action there @parasharrajat. I'm proposing to create follow-up issues to tackle this issue &invest some more time to test this to capture other bugs and handle them holistically by discussing and improving the feature handling.
cc: @robertKozik @sophiepintoraetz @PauloGasparSv

Thank you @Santhosh-Sellavel - that's a great idea. I will close this one out but let's reference this one in your master GH when you create it - lmk if you need a hand wrangling it together!

Reopening to get some movement on these regressions:
https://github.com/Expensify/App/issues/23403
https://github.com/Expensify/App/issues/23184
@Santhosh-Sellavel please feel free to close once a new issue has been created as discussed here.

Reopening to get some movement on these regressions:
#23403 #23184
@Santhosh-Sellavel please feel free to close once a new issue has been created as discussed here.

We are discussing these in this slack thread

Not overdue, still in discussion over at the thread

Hey, we decided over at slack to close this issue and work on the 2 bugs/regressions in their respective issues instead of rolling the feature back and re-implementing it with a doc or fixing both regressions here.
I'll close this issue and comment this on each of the individual bug issues.

Reviewed the details for @Santhosh-Sellavel. Approved for payment in NewDot based on the BZ summary above.

...is Melvin okay? I don't think that's correct, right @PauloGasparSv?

@sophiepintoraetz Yes Melvin is fine. This issue was a referenced in discussion or proposals


typo in UFS_DEVICE_DESCRIPTOR structure (ufs.h)

"UCHAR  dPSAStateTimeout;" should be "UCHAR  bPSAStateTimeout;"

The header has been shipped and in use for some time, so the structure member name cannot be changed to avoid breaking anyone's code. I did add a note to the refpage about its corresponding spec name.


add support for sendgrid using nodemailer and nodemailer-sendgrid-tra…

This adds support for sendgrid. It was tested manually and works for basic message sending.
It makes use of this: https://sendgrid.com/blog/sending-email-nodemailer-sendgrid/
This was the quickest to implement... it is not the ideal method as it adds 1.1mb raw (according to vscode import cost) and sendgrid no longer supports https://github.com/sendgrid/nodemailer-sendgrid-transport.
An ideal method would use node-fetch and this API: https://sendgrid.com/docs/API_Reference/api_v3.html

(Also add a yarn.lock file and lists vscode config files in .gitignore)

Thanks!


SendTimeoutError when upgrading to 0.7.0

Issue Description
The newest 0.7.0 is using deprecated google-api-client and makes the firebase_app_distribution plugin not working
Configuration
  app: "appId",
 firebase_cli_token: ENV['FIREBASE_TOKEN'],
 android_artifact_type: "APK",
 android_artifact_path: "app/build/outputs/apk/production/debug/app-production-debug.apk",
 release_notes_file: options[:releaseNotesFile],
 testers: "testers",
 debug: true

Complete verbose output
[07:26:13]: Installing Ruby gem 'fastlane-plugin-firebase_app_distribution'...
*******************************************************************************
The google-api-client gem is deprecated and will likely not be updated further.
Instead, please install the gem corresponding to the specific service to use.
For example, to use the Google Drive V3 client, install google-apis-drive_v3.
For more information, see the FAQ in the OVERVIEW.md file or the YARD docs.
*******************************************************************************
[07:26:32]: Successfully installed 'fastlane-plugin-firebase_app_distribution'
...
[07:26:32]: Warning: Debug logging enabled. Output may include sensitive information.
[07:26:32]: 🔐 Authenticating with --firebase_cli_token parameter
[07:26:32]: ⌛ Uploading the APK.
D, [2023-08-02T07:26:32.661476 #14] DEBUG -- : Sending HTTP post https://firebaseappdistribution.googleapis.com/upload/v1/projects/XXXX/apps/XXXXX/releases:upload?
D, [2023-08-02T07:42:16.520[91](https://gitlab.com/XXXXX/XXXX/mobile/android/XXXX/-/jobs/XXXX#XXX)3 #14] DEBUG -- : Caught error execution expired
D, [2023-08-02T07:42:16.521087 #14] DEBUG -- : Error - #<HTTPClient::SendTimeoutError: execution expired>
+------------------+----------------------------------------------+
|                          Lane Context                           |
+------------------+----------------------------------------------+
| DEFAULT_PLATFORM | android                                      |
| PLATFORM_NAME    | android                                      |
| LANE_NAME        | android deploy_development_debug_to_firebase |
+------------------+----------------------------------------------+
[07:42:16]: execution expired
+------+---------------------------+-------------+
|                fastlane summary                |
+------+---------------------------+-------------+
| Step | Action                    | Time (in s) |
+------+---------------------------+-------------+
| 1    | default_platform          | 0           |
| 💥   | firebase_app_distribution | [94](https://gitlab.com/XXXX/XXXX/mobile/android/XXXXXX/-/jobs/XXXX#XXXXX)4         |
+------+---------------------------+-------------+
[07:42:16]: fastlane finished with errors

For the error stacktrace:
/usr/lib/ruby/2.7.0/openssl/buffering.rb:326:in `[]=': \e[31m[!] execution expired\e[0m (Google::Apis::TransmissionError)
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:326:in `do_write'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:339:in `block in write'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `each'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `inject'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `write'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/ssl_socket.rb:80:in `<<'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/http.rb:510:in `dump'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/http.rb:962:in `dump'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:517:in `block in query'
	from /usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:515:in `query'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:177:in `query'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1242:in `do_get_block'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1019:in `block in do_request'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1133:in `protect_keep_alive_disconnected'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1014:in `do_request'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1104:in `follow_redirect'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:854:in `request'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/http_command.rb:313:in `execute_once'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/http_command.rb:126:in `block (2 levels) in do_retry'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:61:in `block in retriable'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `times'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `retriable'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/http_command.rb:123:in `block in do_retry'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:61:in `block in retriable'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `times'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `retriable'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/http_command.rb:113:in `do_retry'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/http_command.rb:104:in `execute'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/base_service.rb:418:in `execute_or_queue_command'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/base_service.rb:265:in `http'
	from /var/lib/gems/2.7.0/gems/fastlane-plugin-firebase_app_distribution-0.7.0/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb:256:in `upload_binary'
	from /var/lib/gems/2.7.0/gems/fastlane-plugin-firebase_app_distribution-0.7.0/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb:49:in `run'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:263:in `block (2 levels) in execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/actions/actions_helper.rb:69:in `execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:255:in `block in execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:229:in `chdir'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:229:in `execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:157:in `trigger_action_by_name'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/fast_file.rb:159:in `method_missing'
	from Fastfile:130:in `block (2 levels) in parsing_binding'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/lane.rb:33:in `call'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:49:in `block in execute'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:45:in `chdir'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:45:in `execute'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/lane_manager.rb:47:in `cruise_lane'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/command_line_handler.rb:36:in `handle'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:110:in `block (2 levels) in run'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/command.rb:187:in `call'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/command.rb:157:in `run'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/runner.rb:444:in `run_active_command'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:124:in `run!'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/delegates.rb:18:in `run!'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:[354](https://gitlab.com/XXXXX/XXXXXX/mobile/android/XXXXX/-/jobs/XXXXXX#XXXXX):in `run'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:43:in `start'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/cli_tools_distributor.rb:123:in `take_off'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/bin/fastlane:23:in `<top (required)>'
	from /usr/local/bin/fastlane:23:in `load'
	from /usr/local/bin/fastlane:23:in `<main>'
/usr/lib/ruby/2.7.0/openssl/buffering.rb:326:in `[]=': execution expired (HTTPClient::SendTimeoutError)
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:326:in `do_write'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:339:in `block in write'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `each'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `inject'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `write'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/ssl_socket.rb:80:in `<<'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/http.rb:510:in `dump'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/http.rb:962:in `dump'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:517:in `block in query'
	from /usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:515:in `query'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:177:in `query'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1242:in `do_get_block'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1019:in `block in do_request'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1133:in `protect_keep_alive_disconnected'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1014:in `do_request'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1104:in `follow_redirect'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:854:in `request'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/http_command.rb:313:in `execute_once'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/http_command.rb:126:in `block (2 levels) in do_retry'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:61:in `block in retriable'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `times'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `retriable'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/http_command.rb:123:in `block in do_retry'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:61:in `block in retriable'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `times'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `retriable'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/http_command.rb:113:in `do_retry'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/http_command.rb:104:in `execute'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/base_service.rb:418:in `execute_or_queue_command'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.0/lib/google/apis/core/base_service.rb:265:in `http'
	from /var/lib/gems/2.7.0/gems/fastlane-plugin-firebase_app_distribution-0.7.0/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb:256:in `upload_binary'
	from /var/lib/gems/2.7.0/gems/fastlane-plugin-firebase_app_distribution-0.7.0/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb:49:in `run'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:263:in `block (2 levels) in execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/actions/actions_helper.rb:69:in `execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:255:in `block in execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:229:in `chdir'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:229:in `execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:157:in `trigger_action_by_name'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/fast_file.rb:159:in `method_missing'
	from Fastfile:130:in `block (2 levels) in parsing_binding'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/lane.rb:33:in `call'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:49:in `block in execute'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:45:in `chdir'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:45:in `execute'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/lane_manager.rb:47:in `cruise_lane'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/command_line_handler.rb:36:in `handle'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:110:in `block (2 levels) in run'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/command.rb:187:in `call'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/command.rb:157:in `run'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/runner.rb:444:in `run_active_command'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:124:in `run!'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/delegates.rb:18:in `run!'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:354:in `run'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:43:in `start'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/cli_tools_distributor.rb:123:in `take_off'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/bin/fastlane:23:in `<top (required)>'
	from /usr/local/bin/fastlane:23:in `load'
	from /usr/local/bin/fastlane:23:in `<main>'

Environment
0.7.0

Library
Version

fastlane
[2.212.2]

fastlane-plugin-firebase_app_distribution
[0.7.0]

This, happened to our team as well.
Currently, forcing to go back to previous version 0.6.1 is our workaround.

@felixlix45 Thanks for the report and sorry you're experiencing this issue.
Just checking, do these logs suggest the HTTP post request was initiated at 7:26:32 and finished at 7:42:16? Or is the log timestamps off because it's running it github actions or some other reason. I'm confused because then it says the action took 94 seconds to run. Trying to get a sense of the timing here since I suspect the default upload timeout was shortened with this latest version.
@donirn if you could share logs with debug: true the firebase_app_distribution action (with any sensitive info removed) that would be helpful as well, thanks.

Hi @lfkellogg, yeah I do also thinks that the timestamps is for the HTTP Post. Where my GitLab CI is stuck at 'Uploading APK' for a moment (~17 minute) then it just failed.
I don't really know why it reports only 92 seconds though

having nearly the same trouble. the stacktrace:
 wrong number of arguments (given 3, expected 2)

/Users/admin/.rvm/gems/ruby-2.6.5/gems/google-api-client-0.52.0/lib/google/apis/core/base_service.rb:128:in `initialize': [!] wrong number of arguments (given 3, expected 2) (ArgumentError)
	from /Users/admin/.rvm/gems/ruby-2.6.5/gems/google-apis-firebaseappdistribution_v1-0.3.0/lib/google/apis/firebaseappdistribution_v1/service.rb:46:in `initialize'
	from /Users/admin/.rvm/gems/ruby-2.6.5/gems/fastlane-plugin-firebase_app_distribution-0.7.0/lib/fastlane/plugin/firebase_app_distribution/helper/firebase_app_distribution_helper.rb:76:in `new'
	from /Users/admin/.rvm/gems/ruby-2.6.5/gems/fastlane-plugin-firebase_app_distribution-0.7.0/lib/fastlane/plugin/firebase_app_distribution/helper/firebase_app_distribution_helper.rb:76:in `init_client'
	from /Users/admin/.rvm/gems/ruby-2.6.5/gems/fastlane-plugin-firebase_app_distribution-0.7.0/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb:37:in `run'
	from /Users/admin/.rvm/gems/ruby-2.6.5/gems/fastlane-2.214.0/fastlane/lib/fastlane/runner.rb:263:in `block (2 levels) in execute_action'

Hello, it is breaking our CI pipelines too since it is forcing Fastlane to use the wrong version of the google dependency:
spec.add_dependency('google-api-client', '~> 0.38')
spec.add_dependency('google-apis-firebaseappdistribution_v1', '~> 0.3.0')

--> causing: https://github.com/fastlane/fastlane/issues/19208

unknown keyword: :changes_not_sent_for_review
[...]
[17:14:19]: fastlane finished with errors
Looking for related GitHub issues on fastlane/fastlane...
➡  supply - unknown keyword: changes_not_sent_for_review
https://github.com/fastlane/fastlane/issues/19208 [closed] 7 💬
10 Jan 2022

More details here too: https://github.com/fastlane/fastlane/issues/19208#issuecomment-903044670

@felixlix45 Could you please try updating to 0.7.1.pre.1? I believe that should fix the timeout issue you are seeing. You can set gem 'fastlane-plugin-firebase_app_distribution', '0.7.1.pre.1' in your fastlane/Pluginfile to pick it up.
@Sega-Zero Can you please file a new issue? That looks like a different problem
@Panajev Similarly, can you please file a new issue? (Even though it looks like it might be the same underlying cause as @Sega-Zero)
Thanks, all.

@Sega-Zero @Panajev In the meantime we've pushed 0.7.1.pre.2 which may fix your issues. Can you please try setting gem 'fastlane-plugin-firebase_app_distribution', '0.7.1.pre.1' in your fastlane/Pluginfile to pick it up, and let me know? Thanks.

Hi @lfkellogg, still go the same issue with 0.7.1.pre.2
Here's the log
| fastlane-plugin-firebase_app_distribution | 0.7.1.pre.2 | firebase_app_distribution_get_latest_release, firebase_app_distribution_create_group, firebase_app_distribution_remove_testers, firebase_app_distribution_delete_group, firebase_app_distribution_add_testers, firebase_app_distribution_get_udids, firebase_app_distribution |
...
[17:57:08]: Warning: Debug logging enabled. Output may include sensitive information.
[17:57:08]: 🔐 Authenticating with --firebase_cli_token parameter
[17:57:08]: ⌛ Uploading the APK.
D, [2023-08-02T17:57:09.019955 #42] DEBUG -- : Sending HTTP post https://firebaseappdistribution.googleapis.com/upload/v1/projects/XXXX/apps/1:XXXX:XXX:XXXX/releases:upload?
D, [2023-08-02T18:11:03.726915 #42] DEBUG -- : Caught error execution expired
D, [2023-08-02T18:11:03.727065 #42] DEBUG -- : Error - #<HTTPClient::SendTimeoutError: execution expired>
+------------------+----------------------------------------------+
|                          Lane Context                           |
+------------------+----------------------------------------------+
| DEFAULT_PLATFORM | android                                      |
| PLATFORM_NAME    | android                                      |
| LANE_NAME        | android deploy_development_debug_to_firebase |
+------------------+----------------------------------------------+
[18:11:03]: execution expired
+------+---------------------------+-------------+
|                fastlane summary                |
+------+---------------------------+-------------+
| Step | Action                    | Time (in s) |
+------+---------------------------+-------------+
| 1    | default_platform          | 0           |
| 💥   | firebase_app_distribution | 834         |
+------+---------------------------+-------------+
[18:11:03]: fastlane finished with errors

full stacktrace:
/usr/lib/ruby/2.7.0/openssl/buffering.rb:326:in `[]=': \e[31m[!] execution expired\e[0m (Google::Apis::TransmissionError)
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:326:in `do_write'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:339:in `block in write'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `each'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `inject'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `write'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/ssl_socket.rb:80:in `<<'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/http.rb:510:in `dump'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/http.rb:962:in `dump'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:517:in `block in query'
	from /usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:515:in `query'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:177:in `query'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1242:in `do_get_block'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1019:in `block in do_request'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1133:in `protect_keep_alive_disconnected'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1014:in `do_request'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1104:in `follow_redirect'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:854:in `request'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/http_command.rb:313:in `execute_once'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/http_command.rb:126:in `block (2 levels) in do_retry'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:61:in `block in retriable'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `times'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `retriable'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/http_command.rb:123:in `block in do_retry'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:61:in `block in retriable'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `times'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `retriable'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/http_command.rb:113:in `do_retry'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/http_command.rb:104:in `execute'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/base_service.rb:418:in `execute_or_queue_command'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/base_service.rb:265:in `http'
	from /var/lib/gems/2.7.0/gems/fastlane-plugin-firebase_app_distribution-0.7.1.pre.2/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb:262:in `upload_binary'
	from /var/lib/gems/2.7.0/gems/fastlane-plugin-firebase_app_distribution-0.7.1.pre.2/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb:54:in `run'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:263:in `block (2 levels) in execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/actions/actions_helper.rb:69:in `execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:255:in `block in execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:229:in `chdir'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:229:in `execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:157:in `trigger_action_by_name'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/fast_file.rb:159:in `method_missing'
	from Fastfile:132:in `block (2 levels) in parsing_binding'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/lane.rb:33:in `call'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:49:in `block in execute'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:45:in `chdir'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:45:in `execute'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/lane_manager.rb:47:in `cruise_lane'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/command_line_handler.rb:36:in `handle'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:110:in `block (2 levels) in run'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/command.rb:187:in `call'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/command.rb:157:in `run'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/runner.rb:444:in `run_active_command'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:124:in `run!'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/delegates.rb:18:in `run!'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:354:in `run'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:43:in `start'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/cli_tools_distributor.rb:123:in `take_off'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/bin/fastlane:23:in `<top (required)>'
	from /usr/local/bin/fastlane:23:in `load'
	from /usr/local/bin/fastlane:23:in `<main>'
/usr/lib/ruby/2.7.0/openssl/buffering.rb:326:in `[]=': execution expired (HTTPClient::SendTimeoutError)
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:326:in `do_write'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:339:in `block in write'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `each'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `inject'
	from /usr/lib/ruby/2.7.0/openssl/buffering.rb:338:in `write'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/ssl_socket.rb:80:in `<<'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/http.rb:510:in `dump'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/http.rb:962:in `dump'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:517:in `block in query'
	from /usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:515:in `query'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:177:in `query'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1242:in `do_get_block'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1019:in `block in do_request'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1133:in `protect_keep_alive_disconnected'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1014:in `do_request'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:1104:in `follow_redirect'
	from /var/lib/gems/2.7.0/gems/httpclient-2.8.3/lib/httpclient.rb:854:in `request'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/http_command.rb:313:in `execute_once'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/http_command.rb:126:in `block (2 levels) in do_retry'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:61:in `block in retriable'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `times'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `retriable'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/http_command.rb:123:in `block in do_retry'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:61:in `block in retriable'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `times'
	from /var/lib/gems/2.7.0/gems/retriable-3.1.2/lib/retriable.rb:56:in `retriable'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/http_command.rb:113:in `do_retry'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/http_command.rb:104:in `execute'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/base_service.rb:418:in `execute_or_queue_command'
	from /var/lib/gems/2.7.0/gems/google-apis-core-0.11.1/lib/google/apis/core/base_service.rb:265:in `http'
	from /var/lib/gems/2.7.0/gems/fastlane-plugin-firebase_app_distribution-0.7.1.pre.2/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb:262:in `upload_binary'
	from /var/lib/gems/2.7.0/gems/fastlane-plugin-firebase_app_distribution-0.7.1.pre.2/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb:54:in `run'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:263:in `block (2 levels) in execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/actions/actions_helper.rb:69:in `execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:255:in `block in execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:229:in `chdir'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:229:in `execute_action'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:157:in `trigger_action_by_name'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/fast_file.rb:159:in `method_missing'
	from Fastfile:132:in `block (2 levels) in parsing_binding'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/lane.rb:33:in `call'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:49:in `block in execute'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:45:in `chdir'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/runner.rb:45:in `execute'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/lane_manager.rb:47:in `cruise_lane'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/command_line_handler.rb:36:in `handle'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:110:in `block (2 levels) in run'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/command.rb:187:in `call'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/command.rb:157:in `run'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/runner.rb:444:in `run_active_command'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:124:in `run!'
	from /var/lib/gems/2.7.0/gems/commander-4.6.0/lib/commander/delegates.rb:18:in `run!'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:354:in `run'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/commands_generator.rb:43:in `start'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/fastlane/lib/fastlane/cli_tools_distributor.rb:123:in `take_off'
	from /var/lib/gems/2.7.0/gems/fastlane-2.212.2/bin/fastlane:23:in `<top (required)>'
	from /usr/local/bin/fastlane:23:in `load'
	from /usr/local/bin/fastlane:23:in `<main>'

@lfkellogg I created https://github.com/firebase/fastlane-plugin-firebase_app_distribution/issues/335 to track the issue and the testing I am doing with pre.2.

@lfkellogg,  yeah after adding upload_timeout: 1200, the upload is succeed with a ridiculous amount of time to upload. Here's my comparison between 0.6.1 vs 0.7.1.pre.2
0.6.1
D, [2023-08-01T09:49:52.108197 #15] DEBUG -- request: POST https://firebaseappdistribution.googleapis.com/upload/v1/projects/XXX/apps/1:XXX:XXX:XXX/releases:upload
D, [2023-08-01T09:49:56.779865 #15] DEBUG -- response: Status 200

0.7.1.pre.2
D, [2023-08-02T20:16:45.021846 #45] DEBUG -- : Sending HTTP post https://firebaseappdistribution.googleapis.com/upload/v1/projects/XXX/apps/1:XXX:XXX:XXX/releases:upload?
D, [2023-08-02T20:30:30.399632 #45] DEBUG -- : 200

It's the same issue.
When I lowered the version to 0.6.1, the upload speed was improved.

@felixlix45 @jieey1140 A fix for the slow uploads issue is now available in version 0.7.2.pre.1. Can you please try setting gem 'fastlane-plugin-firebase_app_distribution', '0.7.2.pre.1' in your fastlane/Pluginfile to pick it up, and let me know if your binary uploads are faster? Thanks.

@lfkellogg
[15:26:38]: Warning: Debug logging enabled. Output may include sensitive information.
[15:26:38]: 🔐 Authenticating with --service_credentials_file path parameter: fastlane/service-account.json
[15:26:38]: ⌛ Uploading the APK.
D, [2023-08-04T15:26:38.685182 #51767] DEBUG -- request: POST https://firebaseappdistribution.googleapis.com/upload/v1/projects/XXX/apps/1:XXX:XXX:XXX/releases:upload
D, [2023-08-04T15:26:46.632563 #51767] DEBUG -- response: Status 200
D, [2023-08-04T15:26:46.632763 #51767] DEBUG -- response: {
  "name": "projects/XXX/apps/1:XXX:XXX:XXX/releases/-/operations/4f4d8c2fe086edd7945d7ca3b4d3ccde6fa04724c67ae38c5"
}

D, [2023-08-04T15:26:46.634091 #51767] DEBUG -- request: GET https://firebaseappdistribution.googleapis.com/v1/projects/XXX/apps/1:XXX:XXX:XXX/releases/-/operations/4f4d8c2fe086e77ca3b4d3ccde6fe38c5
D, [2023-08-04T15:26:47.864738 #51767] DEBUG -- response: Status 200
D, [2023-08-04T15:26:47.864965 #51767] DEBUG -- response: {
  "name": "projects/XXX/apps/1:XXX:XXX:XXXreleases/-/operations/4f4d824c67ae38c5",
  "done": true,

Above is the upload speed of the existing 0.6.1.
15:26:38~15:26:46
=====================================================
  [15:29:18]: 🔐 Authenticating with --service_credentials_file path parameter: fastlane/service-account.json
[15:29:19]: ⌛ Uploading the APK.
D, [2023-08-04T15:29:19.403816 #52152] DEBUG -- request: POST https://firebaseappdistribution.googleapis.com/upload/v1/projects/XXX/apps/1:XXX:XXX:XXX/releases:upload
D, [2023-08-04T15:29:26.349074 #52152] DEBUG -- response: Status 200
D, [2023-08-04T15:29:26.349181 #52152] DEBUG -- response: {
  "name": "projects/XXX/apps/1:XXX:XXX:XXX/releases/-/operations/4f4d8c2fe0724c67ae38c5"
}

D, [2023-08-04T15:29:26.353348 #52152] DEBUG -- : Sending HTTP get https://firebaseappdistribution.googleapis.com/v1/projects/XXX/apps/1:XXX:XXX:XXX/releases/-/operations/4f4d8c2fe0824c67ae38c5?
D, [2023-08-04T15:29:27.579338 #52152] DEBUG -- : 200

Above is the upload speed of the existing. 0.7.2.pre.1
15:29:18 ~ 15:29:26
=====================================================
We now see that the upload speed of the previous 0.6.1 version is the same in the new. 0.7.2.pre.1 version! :)

This is now fixed in release v0.7.2.

Hello everyone, I'm getting this error, can anyone help me please?
`Fetching google-apis-core-0.11.1.gem
Fetching google-apis-firebaseappdistribution_v1-0.3.0.gem
Fetching fastlane-plugin-firebase_app_distribution-0.7.2.gem
[13:51:57]: Successfully installed 'fastlane-plugin-firebase_app_distribution'
[13:51:57]: Error loading plugin 'fastlane-plugin-firebase_app_distribution': Unable to activate google-apis-firebaseappdistribution_v1-0.3.0, because google-apis-core-0.7.0 conflicts with google-apis-core (>= 0.11.0, < 2.a)
[13:51:57]: It seems like you wanted to load some plugins, however they couldn't be loaded
[13:51:57]: Please follow the troubleshooting guide: https://docs.fastlane.tools/plugins/plugins-troubleshooting/
+-------------------------------------------+-----------+------------------+
|                               Used plugins                               |
+-------------------------------------------+-----------+------------------+
| Plugin                                    | Version   | Action           |
+-------------------------------------------+-----------+------------------+
| fastlane-plugin-firebase_app_distribution | undefined | No actions found |
+-------------------------------------------+-----------+------------------+
[!] No actions were found while loading one or more plugins
Please use bundle exec fastlane with plugins
More info - https://docs.fastlane.tools/plugins/using-plugins/#run-with-plugins`

@fcsjesus Can you please create a new issue for this?


DMN New Editor backward incompatibility for data type expression constraints

This seems to be a very interesting issue of using New vs Classic DMN editor.
We have this DMN model, from its content, created probably using the Classic DMN Editor.
reproducer.dmn.txt
Please notice, it contains invalid constraint definition not(null) and (string length()>0). But it is good four reporting this issue.
New DMN Editor
Once you upload the model into sandbox, fill some string for the user, you will see error. This is expected.

Then fix the constraint to be string length(?)>0), and again check the run results. There will be still an error. This is not expected.

Classic DMN Editor
Do the same steps as above using Classic editor.
In the first phase, the error will be the same, that is expected.

In the second phase, the classic editor will start to work and user see the execution results. This is correct behavior that should be also for the NEW DMN Editor.

Thanks @jomarko
@baldimir @yesamer : there is a strange behavior here, beside the one mentioned by Jozef.
The original dmn is invalid ->
string length()>0 because lenght() requires a parameter, but in my local test it succeed validation, and even the behavior from editors suggest that, since the error is thrown during execution, and not during import (IINW) 🤔

@baldimir @yesamer
On further investigation, here's the issues I found:

the constraint is invalid in first place, but constraints are not checked during validation
during execution, the constraint fails because of the wrong syntax (i.e. there is a method not found error) but this is swalloped up and hidden
due to above, the end result of the unarytest is "null", so the message misleading says that "a" is invalid, while it is actually valid (it is the constraint itself that is wrongly written)

@tiagobento Not exactly, it is an issue of implementation.
Current implementation has a "validation" API and execution API.
But constraints are not "validated" in the former, so you do not see that the model is invalid in first place.
Then, during execution, since they are invalid, the evaluation fails (with a null) but the message indicates the input.
So, this is definetely a bug to be fixed  on the engine itself - I would say urgent, IMO.


Notification Server Changes

What current issue(s) does this address, or what feature is it adding?

Change notification transfer event format to use string quoted integer
-Fix Notification token list to include correct hash for contract and token
Closes #647
Should fix https://github.com/CityOfZion/neo-scan/issues/354

Please check the following, if applicable:

[ ] Did you add any tests?
[x] Did you run make lint?
[x] Did you run make test?
[x] Are you making a PR to a feature branch or development rather than master?
[x] Did you add an entry to CHANGELOG.rst? (if not, please do)

Coverage remained the same at 79.557% when pulling 7873c48aa6279e17117a67231d7043ba9822aa4b on notification-server-changes into 1990beaf97c01051b75de1867f6a547eee7f5d9e on development.


Further indent podAntiAffinity matchLabels

Currently, it ends up on the same depth as matchLabels: in my testing running helm template:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              topologyKey: kubernetes.io/hostname
              labelSelector:
                matchLabels:
                app.kubernetes.io/component: redpanda-statefulset
                app.kubernetes.io/instance: redpanda
                app.kubernetes.io/name: redpanda

Which kubernetes seems to accept and interpret correctly, but when I run this yaml through any post-processing (eg yq) it "fixes" matchLabels: not having a value and sets it to null, causing the labels to be interpreted as keys under labelSelector instead, which kubernetes rejects as not matching the sts spec.

Strange that yq is less permissive than Kubernetes' (go's) YAML parser.

Yeah, this one is fascinating for sure. yq reads it fine, but makes a different assumption about the ambiguous indentation and assumes this means matchLabels: null, which is what comes out when you run this through yq.
I'll try to update the tests!

Hm, the tests all appear to have the correct (2 space) indentation already, and this makes them 4 spaced. Could be something on my side? I'll try to dig in more.

Just as a quick double check, which version of helm and the chart have you been working with?

Ah, gotcha! I wrote up an issue to get some tests on this matter as I'm guessing there are other cases of this floating around. Thanks for the fix and for bringing this to our attention!


docadd update key doc

Problem summary
At present, only the value column can be modified through the update command,
and the modification of the key column can be done by flinkcdc synchronization
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

LGTM

run build all

run buildall


[Feature] Add API endpoint for deleting files

I want to work on this issue, it would be great if you assign this to me

@ankit-pn You have been assigned. Make sure to check out the documentation about contributing.

I have restructured data package and pushed the change for delete api. I have tested the API on my local machine and it is working good. Included in on  #28


Windows 10 error playing with ".ogg" file

>>> playsound.playsound(os.path.join(os.getcwd(),'bark.ogg'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Program Files\Python37-32\lib\site-packages\playsound.py", line 35, in _playsoundWin
    winCommand('open "' + sound + '" alias', alias)
  File "D:\Program Files\Python37-32\lib\site-packages\playsound.py", line 30, in winCommand
    '\n    ' + errorBuffer.value.decode())
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb6 in position 2: invalid start byte

I'm happy to accept a PR that adds in support for .ogg, so long as it doesn't add in more dependencies, but I don't know of a way of adding that support myself so I'm just going to close the issue.


How to define the nchr for the pipeline

Hello HapHiC developers,
I am handling a species with ~46 chromosomes.According to our previous HiC result, this species seems to be a Triploid.
However, we also found that some clusters maybe diploid on the HiC heatmap. We are not quite sure at this moment.
So, how should I define the 'nchr' while run the HapHiC pipeline？Should I use 46*3=138？
Regards,
Zixi

Hi Zixi,
I'm not quite sure about your description. If 46 is the haploid chromosome number, and your genome assembly is haplotype-phased (e.g., p_utg or catenated hap*.p_ctg), the nchr parameter should be set to 46 * 3 = 138.
Best,
Xiaofei

Thanks for your reply, I will try.


Sync timers on the system time

Would be nice for things like showing the current time.

I'd assign myself if I could :)

Sure. I would, however suggest to use the chrono crate, as it gives you monotonous time types that can be used to do some meaningful math :)


Configurable background per view

Currently we have the option of just changing the background.jpg but it would be really handy if we could have a configuration option to specify a different background for each view.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/31177360-configurable-background-per-view?utm_campaign=plugin&utm_content=tracker%2F580790&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F580790&utm_medium=issues&utm_source=github).

Interesting idea, I'm curious - could you please let me know what sorts of backgrounds you'd like to be using? Are they to make it easier to distinguish the monitors, make them prettier, add the team/company logo, other?

So we have a large number of jobs running for multiple projects on our Jenkins server which we have already split up using cloudbees folders. In those folders we have a number of different  subfolders building code branches;
root
+--Project
+---Branch 1
+ Job 1
+ Job 2
+ Job 3
+---Branch 2
+ Job 1
+ Job 2
+--Project
+---Branch 1
+ Job 1
.....
We use views at the Project and Branch level so that different groups of people can have an overview of their own granularity of caring, which then gets displayed permanently on a monitor near their team :)
So the Engineers will look at the Branch level view so that they can see which actual jobs they've broken, the team Leads will look at the Project level view so they can see the state of everything underneath it.
In our case each Project is a big 'multimedia thing' which comes with it's own concept art and other imagery which the teams would like in the background of their individual views. It also helps quickly identify which view you're looking at. It also looks pretty :)
I've already changed the default background to be one of these pieces of concept art and changed the css so that non-running successful (green) projects are shown at 30% alpha and it looks awesome. But technically it's only awesome for one team. The more of the concept art you can see, the better the state of the project, as only broken jobs show up fully opaque.
Incidentally as a side note, I tried downloading the source for the plugin and building it myself with the idea that I could maybe make some of the changes myself and push those changes back into the dev line, but I couldn't get it to build successfully on Windows and i'm struggling with CentOS too. Do you happen to have a guide as to what you're running to do the development on in the first place? I'd love to be able to get more involved with updating plugins, but so far all i've done is create my own build plugins for our pipeline. Apparently getting someone else's code building is a whole different ball game. :/
Anyway - keep up with the plugin - it's awesome :)


Fixed spacing on darker sections (mobile)

Probably pretty bodged, but it works.

I also realise I pushed package-lock so that's why there's so many line additions. Oops.

Grrr npm :P


[Release 0.8.3] Merge master into dev

Hi @jianghaolu, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.azure.com.

TTYL, AZPRBOT;