feat: Abstract LocalStorage Usage in Indicator.tsx

Description
Currently, the Indicator.tsx component directly accesses localStorage to retrieve and manage the OS version. This approach can lead to code that is harder to test and maintain. To improve the codebase, we should abstract the localStorage interactions into a custom hook.
Proposed Solution
Create a custom hook, useOsVersion, to encapsulate the logic for accessing and updating the OS version from localStorage. This hook will manage the state and side effects related to localStorage, making the Indicator.tsx component cleaner and more focused on its primary responsibilities.
Benefits

Improved Code Readability: The Indicator.tsx component will be more focused and easier to understand.
Better Testability: The logic for managing localStorage will be isolated, making it easier to write unit tests.
Reusability: The useOsVersion hook can be reused in other components if needed.

Additional Notes

Edge Cases: Ensure that the hook handles any edge cases, such as localStorage being unavailable in certain environments (e.g., server-side rendering).
Error Handling: Consider adding error handling within the hook to manage potential issues with localStorage, such as quota exceeded errors or JSON parsing errors.

By abstracting the localStorage usage into a custom hook, we can enhance the maintainability and scalability of our codebase. This approach also promotes the separation of concerns, making each component and hook responsible for a single aspect of the application's functionality.

@Arindam200 I am interested in working on this issue. Please assign it to me.

@Arindam200 I am interested to work on this issue. Please assign it to me.

Go ahead @brajeshgiri .


Create your own Enumerable

Project requirements
Check offical documentation about the following 3 methods in Enumerable. Make sure that you understand what they are doing.
description of #all? method
description of #any? method
description of #filter method
Create a class MyList that has an instance variable @list.
In MyList implement a method #each that yields successive members of @list and uses the MyEnumerable module.
Create a module MyEnumerable that implements the following methods (they should have the same funcionality as methods in Enumerable):
#all?
#any?
#filter
Each class and module should has a separate .rb file.

How else should I have contributed to the project if not by adding code to
the code base?
Can you elaborate on why you feel my contribution wasn’t enough?
Errytage Design
On Fri, 29 Sep 2023 at 10:12, Juliana Ifionu @.***>
wrote:

@.**** commented on this pull request.
Hi @Abdulwhbhussain https://github.com/Abdulwhbhussain and
@Errytagedesign https://github.com/Errytagedesign,
While you made a great effort in this project, unfortunately, I cannot
proceed to review your code.
Invalid Code Review Request

While we are free to make additional changes unrelated to the
project, everyone on the team must still make commits that are pertaining
to the project requirements. The second collaborator, @Errytagedesign
https://github.com/Errytagedesign, made changes to the project but
they were irrelevant to the project guidelines, and so cannot count as a
contribution.

Your Code Review Request will be marked as invalid in your Dashboard, so
please submit a new one once you are ready 🙏
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something
is not 100% clear.
Please, do not open a new Pull Request for re-reviews. You should use the
same Pull Request submitted for the first review, either valid or invalid
unless it is requested otherwise.
Invalid Code Review Request does not count into the code reviews limit.
—
Reply to this email directly, view it on GitHub
https://github.com/Abdulwhbhussain/My-Enumerable/pull/1#pullrequestreview-1650381145,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AS6UVO2D7D3HLD4P5SHTTNDX42GIRANCNFSM6AAAAAA5LSACC4
.
You are receiving this because you were mentioned.Message ID:
@.***>


Add alpine support when layering sshd on top

This change makes it possible to layer sshd on top of an alpine image.
e.g https://github.com/csabapalfi/hello-alpine-node can now be deployed with clocker.
I tested locally and using the SshdDockerfile results in an SSHable alpine image.

onbox.base.dir.skipResolution: true is required (and potentially some more changes around runtime directory setup)


Fix highlighting of binary %, & and ^ and unary + and -

Used the Godot 2 theme below to highlight the fix with highlighting unary - and +:

Before
After

Bonus: Replaced instances of str.length() with line_length throughout the highlighter for consistency.
Fixes #61646
Implements most of https://github.com/godotengine/godot-proposals/issues/4874
Supersedes PR #63044 (It only had the % highlighting fix)

Realized today this PR will put a number of highlighting bugs in the spotlight, even though I didn't actually introduce them.

Ligatures are colored like their last character, and we already have a problematic case with ]# and <$. This PR introduces quite a few new problems. These ligatures aren't relevant to GDScript and should probably be broken up anyway. See https://github.com/godotengine/godot/issues/63605#issuecomment-1199105222
&& is a ligature and always binary. Currently it's highlighted pink-white, which makes the ligature highlighted in white. With the PR it's colored white-pink, which makes the ligature colored in pink.

Figured out a good (in my opinion) way to fix the second issue without using the tokenizer.

Added ~ to the rule since it's also a mathematical unary operator.

Caught up highlighting to handle all proper syntax around unary/binary & and ^ without spacing. To the two people who would ever use such horrible syntax...

It's highlighted properly now! You're welcome.

Thank you and congrats on your first contribution to Godot Engine's source! 🎉


Consolidate the use of URL parameters to specify database override

There are actions for which we want to provide an override for the database
to use, like when launching Spec11 and Invoicing pipelines. It make sense to
consolidate around the same parameter provided from the same module for
consistency in all cases, instead of defining an override for each action.

This change is

Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @gbrodman, @jianglai, and @sarahcaseybot)

core/src/main/java/google/registry/reporting/billing/GenerateInvoicesAction.java, line 95 at r2 (raw file):
Previously, jianglai (Lai Jiang) wrote…
database is, but this.database isn't, right?

Lol you're right. I think I moved it before further refactoring that makes the move unnecessary. Fixed.


Update also docs/antora.yml when preparing a release

@ppalaga I went ahead and fixed that earlier than expected. Enjoy 😉

Thanks a lot, @gastaldi!


SPWebAppAuthentication: Fixes #1105

Pull Request (PR) description
SPWebAppAuthentication: Fixes issue where Test method return false on NON-US OS.
This Pull Request (PR) fixes the following issues

Fixes #1105

Task list

[x] Added an entry under the Unreleased section of the change log in the CHANGELOG.md.
Entry should say what was changed, and how that affects users (if applicable).
[ ] Resource documentation added/updated in README.md in the resource folder.
[ ] Resource parameter descriptions added/updated in schema.mof
and comment-based help.
[ ] Comment-based help added/updated.
[ ] Localization strings added/updated in all localization files as appropriate.
[ ] Examples appropriately added/updated.
[ ] Unit tests added/updated. See DSC Resource Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Resource Testing Guidelines.
[ ] New/changed code adheres to DSC Resource Style Guidelines and Best Practices.

This change is

Codecov Report

Merging #1106 into dev will decrease coverage by <1%.
The diff coverage is 100%.

@@          Coverage Diff          @@
##             dev   #1106   +/-   ##
=====================================
- Coverage     92%     92%   -1%
=====================================
  Files        120     120
  Lines      13296   13296
=====================================
- Hits       12330   12302   -28
- Misses       966     994   +28


Session Management - Too many old session files

CodeIgniter 3 relies on PHP's native grabage collector. But the native garbage collector is disabled by default since the default probability the gc to run is 0/1000 which means it basically runs never.
This leads into thousands of files in /tmp which won't get deleted unless you reboot the server or delete them manually. Especially on big installations which have a really long uptime this will cost a lot of performance.
To fix this we set the probability of the GC to run manually to 1/1000 which means that approx. every 1000 request will trigger the GC to clean up stuff in /tmp.
This does not affect the "Keep-Login" Feature or any active session.
PS: The command gc_collect_cycles(); only cleans up memory and has no effect for the sessions.
More Information you can find here:
https://www.php.net/manual/en/session.configuration.php#ini.session.gc-probability
https://www.php.net/manual/en/session.configuration.php#ini.session.gc-divisor
https://osvaldas.info/enabling-codeigniters-garbage-collector/

Tnx to @m0urs for this hint


API design

The current API is more of a sketch of what this could look like. On chat there seems to be a sentiment that the current API might not suffice for more complex man pages.
I'm opening this issue to gather examples of complex man pages, and to help shape the design of the crate. This should hopefully allow us to get a deeper understanding of which API we can, and should expose.

Not sure but my guess is more a matter of single sourcing

header information pulled from Cargo.toml
flags pulled from clap
body pulled from markdown that can also be used as web documentation

Granted, if this is a lower level API, then it might make sense to not have all of that built in

I think clap actually has a really neat API. Taking some notes on the structure would probably be a good idea. https://github.com/kbknapp/clap-rs#quick-example
extern crate clap;
extern crate clap_md;

use clap::{App, AppSettings, Arg, SubCommand};
use clap_md::app_to_md;

fn main() {
  let a = App::new("testapp")
    .about("Pointless application")
    .setting(AppSettings::SubcommandRequiredElseHelp)
    .author("Katharina Fey<EMAIL_ADDRESS>    // .author("Yosh Wuyts<EMAIL_ADDRESS>    .long_about("Lorem Ipsum bla bla bla")
    .arg(Arg::with_name("debug").short("d").help("Make program output debug messages"))
    .arg(Arg::with_name("output").short("o").takes_value(true).help("Output File"))
    .subcommand(SubCommand::with_name("foo").arg(Arg::with_name("bar").short("b").long("barr")));

  let markdown = app_to_md(&a, 1).unwrap();
  println!("{}", markdown);
}


Configurable waiting window

This addresses #6:
A new flag --waiting-window is introduced, which defines a custom waiting duration before applying changes. It can be set to any duration value depending on user's needs and can be disabled entirely with a 0 value.
In this latter case an additional performance step is done, as the queue will be completely depleted before actually working in case other events are waiting as well. This improves performance because it still allows the worker and the SDWAN to work in bulk mode, instead of just starting working after the first operation/event is received.

Just rebased to main, merge with commit when you feel it's good! :)


enhancement: name and syntax checks

I'm sure this is on the roadmap and it probably follows hand in glove with better pre-fills, but it would be very nice for an
indicator that the entry is valid or not. So for CAGEAnimation there is 'playspeed' for CMD Animation it's 'PlaySpeed'.
Those two automatically prefill. Many others do not and will allow incorrect data type or parameter.
Underscore vs words placed together with a capital letter for each and capital vs lower case letter check would be helpful.
However, I recently found that on the speech and speechscript functions the event is 'sound_event' not 'sound_bank' which
I mistakenly typed (data type 'sound_event' is not present in the list) and only through compare did I locate where I'd gone wrong.
Also, while copy/pasting I accidentally added a leading space for one of the event names which is a string.
I almost didn't notice it until I manually typed the name and found the space.

I've extended support for all parameters in the parameter selection window, so I'm going to close this issue, as it acts as the auto complete functionality you're after here.


Add aws codeguru

This PR adds support for aws codeguru.

@t-maoshengye Please add new nodes to the indexes.cypher

@t-maoshengye I will have a closer look soon, but please also add the ModuleSyncMetadata. I know I need to also add that suggestion to the documentation.

Not stale


Removing trailing semi colons after return statements is not safe when conditional statements are present

fn host_perf_check() -> Result<()> {
	#[cfg(not(build_type = "release"))]
	return Err(PerfCheckError::WrongBuildType.into())

	#[allow(unreachable_code)]
	#[cfg(not(feature = "hostperfcheck"))]
	return Err(PerfCheckError::FeatureNotEnabled { feature: "hostperfcheck" }.into())

	#[cfg(all(build_type = "release", feature = "hostperfcheck"))]
	{
		crate::host_perf_check::host_perf_check()?;
		Ok(())
	}
}

diff --git a/cli/src/command.rs b/cli/src/command.rs
index 79dc81f3e61..c816d2e6acb 100644
--- a/cli/src/command.rs
+++ b/cli/src/command.rs
@@ -247,11 +247,11 @@ macro_rules! unwrap_client {
 /// Should only be used in release build since the check would take too much time otherwise.
 fn host_perf_check() -> Result<()> {
        #[cfg(not(build_type = "release"))]
-       return Err(PerfCheckError::WrongBuildType.into());
+       return Err(PerfCheckError::WrongBuildType.into())

        #[allow(unreachable_code)]
        #[cfg(not(feature = "hostperfcheck"))]
-       return Err(PerfCheckError::FeatureNotEnabled { feature: "hostperfcheck" }.into());
+       return Err(PerfCheckError::FeatureNotEnabled { feature: "hostperfcheck" }.into())

        #[cfg(all(build_type = "release", feature = "hostperfcheck"))]
        {
(END)

rustfmt introduces the above changes rustfmt 1.4.38-nightly (6dd6840 2022-05-11) up to and including rustfmt 1.5.1-nightly (9a7b7d5 2022-07-19) which makes the compilation fail with:
error: expected one of `.`, `;`, `?`, `}`, or an operator, found `#`
   --> cli/src/command.rs:252:2
    |
250 |     return Err(PerfCheckError::WrongBuildType.into())
    |                                                      - expected one of `.`, `;`, `?`, `}`, or an operator
251 |
252 |     #[allow(unreachable_code)]
    |     ^ unexpected token
error: could not compile `polkadot-cli` due to previous error
Caused by:

@drahnr just to be clear, the updates you made reflect what the output is?
I assume this was your input:
fn host_perf_check() -> Result<()> {
	#[cfg(not(build_type = "release"))]
	return Err(PerfCheckError::WrongBuildType.into());

	#[allow(unreachable_code)]
	#[cfg(not(feature = "hostperfcheck"))]
	return Err(PerfCheckError::FeatureNotEnabled { feature: "hostperfcheck" }.into());

	#[cfg(all(build_type = "release", feature = "hostperfcheck"))]
	{
		crate::host_perf_check::host_perf_check()?;
		Ok(())
	}
}

Let me add the rustfmt config ,. I totally forgot about that


grpcio-sys requires go?

On two separate systems, compilation of sys fails when go is not installed.
The readme does not seem to indicate this is a requirement, am I doing something wrong here?
I would really prefer not to have go installed for compilation on my dev machine, is it possible?

This can be closed, because https://github.com/pingcap/grpc-rs/pull/199 was merged


Support Cascade Delete When Removing Karpenter from my Cluster

Description
What problem are you trying to solve?
I'd like to be able to configure cascading delete behavior for Karpenter so that I can set values on NodePool deletion or on CRD deletion that convey to Karpenter that I want a more expedited termination of my nodes rather than waiting for all nodes to fully drain.
Right now, it's possible for nodes to hang due to stuck pods or fully blocking PDBs due to our graceful drain logic. Because a NodePool deletion or CRD deletion causes all the nodes to gracefully drain, it's also possible for these deletion operations to hang, halting the whole process. Ideally, a user could send through something like --grace-period when they are deleting a resource and Karpenter could reason about how to pass that down to all resources that the deletion cascades to.
Minimally, we should allow CRD deletions to get unblocked so that cluster operators can uninstall Karpenter from clusters without being blocked by graceful node drains that may hang.
An initial implementation of this was tried here https://github.com/kubernetes-sigs/karpenter/pull/466 and there was some discussion in the community about enabling the ability to pass gracePeriod through to CRs in the same way that you can pass them through to pods today to affect the deletionTimestamp for a CR, allowing controller authors to build custom logic around this gracePeriod concept.

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

/reopen

/remove-lifecycle rotten

/triage accepted

Discussed this in WG today: The consensus was that folks, in general, still want the ability to have the graceful termination of their nodes -- so they don't want Karpenter to always do a forceful termination of all the nodes on their behalf. There are currently workarounds with the TerminationGracePeriod implementation that would allow users to start the teardown of Karpenter's CRDs, have the NodeClaims start to be terminated, and then have a user or automation annotate all of the nodes with the karpenter.sh/nodeclaim-termination-timestamp to mark the time that the NodeClaim has to be removed by.
In the case that you want forceful termination, you could mark the timestamp to be the current time and then everything should start forcefully removing itself, with the instances that were launched by Karpneter torn down as well.


Missing customizing for commercetools.cache.factory / CacheAdapterFactory

The CacheAdapterFactory (commercetools.cache.factory) is not designed well in core component, so is has soft dependencies to several cache providers. Instead of internal try to find a suitable cache provide a way to inject a cache instance directly into constructor eg use psr-6 cache only. is will also help to support new symfony core cache component.
Also provide a configuration then to replace a given default cache service.

With PHP-SDK 1.1 I replaced the cache interface with the possibility to use a PSR-6 cache. It's also planned to use the symfony 3.1 PSR-6 cache adapters.


Error parsing:  Project name python-harborclient was given, but was not able to be found

Error building image.
Downloaded the lasted stuff. Did the following
$ wget https://github.com/int32bit/python-harborclient/archive/master.zip
$ cd python-harborclient-master
$ docker build -t  myuser/harborclient .
Got the following error:
Removing intermediate container 4d7de44b27bd
---> 653d905e9a67
Step 5/6 : RUN set -ex         && cd /opt/harborclient         && python setup.py install         && rm -rf /opt/harborclient
---> Running in 4750423d952e

cd /opt/harborclient
python setup.py install
ERROR:root:Error parsing
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/pbr/core.py", line 96, in pbr
attrs = util.cfg_to_args(path, dist.script_args)
File "/usr/local/lib/python2.7/site-packages/pbr/util.py", line 258, in cfg_to_args
pbr.hooks.setup_hook(config)
File "/usr/local/lib/python2.7/site-packages/pbr/hooks/init.py", line 25, in setup_hook
metadata_config.run()
File "/usr/local/lib/python2.7/site-packages/pbr/hooks/base.py", line 27, in run
self.hook()
File "/usr/local/lib/python2.7/site-packages/pbr/hooks/metadata.py", line 26, in hook
self.config['name'], self.config.get('version', None))
File "/usr/local/lib/python2.7/site-packages/pbr/packaging.py", line 816, in get_version
name=package_name))
Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name python-harborclient was given, but was not able to be found.
error in setup command: Error parsing /opt/harborclient/setup.cfg: Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name python-harborclient was given, but was not able to be found.
The command '/bin/sh -c set -ex         && cd /opt/harborclient         && python setup.py install         && rm -rf /opt/harborclient' returned a non-zero code: 1

Pip may use latest git tag or branch name as distribute version,  wget  master branch may lose all these info. I suggest you clone this whole project using git as follows:
git clone https://github.com/int32bit/python-harborclient.git
cd python-harborclient

The clone worked.  Thanks for your supoort


⚠ Bofrost.gr has degraded performance

In e35bb95, Bofrost.gr (https://www.bofrost.gr) experienced degraded performance:

HTTP code: 200
Response time: 4032 ms

Resolved: Bofrost.gr performance has improved in 9c546a3 after 8 minutes.


[cloud_firestore] INTERNAL ASSERTION FAILED: A transaction object cannot be used after its update callback has been invoked.

Describe the bug
App crash when adding new data. It doesn't print any error in flutter developement. But if you open android log it show:
 java.lang.RuntimeException: An error occurred while executing doInBackground()         at android.os.AsyncTask$3.done(AsyncTask.java:318)         at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:354)         at java.util.concurrent.FutureTask.setException(FutureTask.java:223)         at java.util.concurrent.FutureTask.run(FutureTask.java:242)         at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:243)         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)         at java.lang.Thread.run(Thread.java:761)      Caused by: java.lang.AssertionError: INTERNAL ASSERTION FAILED: A transaction object cannot be used after its update callback has been invoked.         at com.google.firebase.firestore.util.Assert.fail(com.google.firebase:firebase-firestore@@21.3.0:46)         at com.google.firebase.firestore.util.Assert.hardAssert(com.google.firebase:firebase-firestore@@21.3.0:31)         at com.google.firebase.firestore.core.Transaction.ensureCommitNotCalled(com.google.firebase:firebase-firestore@@21.3.0:246)         at com.google.firebase.firestore.core.Transaction.lookup(com.google.firebase:firebase-firestore@@21.3.0:81)         at com.google.firebase.firestore.Transaction.getAsync(com.google.firebase:firebase-firestore@@21.3.0:191)         at com.google.firebase.firestore.Transaction.get(com.google.firebase:firebase-firestore@@21.3.0:228)         at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(CloudFirestorePlugin.java:569)         at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(CloudFirestorePlugin.java:564)         at android.os.AsyncTask$2.call(AsyncTask.java:304)         at java.util.concurrent.FutureTask.run(FutureTask.java:237)         at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:243)          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)          at java.lang.Thread.run(Thread.java:761)
To Reproduce
Steps to reproduce the behavior:
This is so occasional.

Add new data.
Get data

Expected behavior
App should not crash

Seems to same here. iOS is good. Only android appear.
2020-02-11 15:19:18.335 13830-14111/? E/AndroidRuntime: FATAL EXCEPTION: AsyncTask #6
    Process: live.effy.app.dev, PID: 13830
    java.lang.RuntimeException: An error occurred while executing doInBackground()
        at android.os.AsyncTask$3.done(AsyncTask.java:354)
        at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:383)
        at java.util.concurrent.FutureTask.setException(FutureTask.java:252)
        at java.util.concurrent.FutureTask.run(FutureTask.java:271)
        at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)
     Caused by: java.lang.AssertionError: INTERNAL ASSERTION FAILED: A transaction object cannot be used after its update callback has been invoked.
        at com.google.firebase.firestore.util.Assert.fail(com.google.firebase:firebase-firestore@@21.3.0:46)
        at com.google.firebase.firestore.util.Assert.hardAssert(com.google.firebase:firebase-firestore@@21.3.0:31)
        at com.google.firebase.firestore.core.Transaction.ensureCommitNotCalled(com.google.firebase:firebase-firestore@@21.3.0:246)
        at com.google.firebase.firestore.core.Transaction.lookup(com.google.firebase:firebase-firestore@@21.3.0:81)
        at com.google.firebase.firestore.Transaction.getAsync(com.google.firebase:firebase-firestore@@21.3.0:191)
        at com.google.firebase.firestore.Transaction.get(com.google.firebase:firebase-firestore@@21.3.0:228)
        at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(CloudFirestorePlugin.java:569)
        at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(CloudFirestorePlugin.java:564)
        at android.os.AsyncTask$2.call(AsyncTask.java:333)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)

This happens to me when running multiple transactions.

This also happens to me when running the same transaction on two devices

I see this as well - and unfortunately including catchError() on runTransaction does not seem to protect against this crash.

Hi, anybody found a solution for this ?

Experiencing the same issue (see #1216)
Despite the title of this issue, it happens on both android and iOS

Tracked this down to Firebase offline use and Transactions.
This will happen when you are using either BATCHWRITES or runTransaction in ANDROID and you have no INTERNET connection/limited Internet connection/or unstable internet connection at the point of where the transaction runs.
So to reproduce, run your code that uses either a  runTransaction (Ensure that internet is not on). By default, TX require ONLINE access and should FAIL immediately where you can catch the exception. For iOS an exception is raised. For Android - no exception is raised and the transaction trys to run regardless.
No wait a while (5-10 secs) , then turn on INTERNET - after about 10 or so seconds when connection re-establishes itself, FLUTTER crashes.
I dont get this happening in iOS. I recall this working some time back so expect this to be a configuration/regression issue with cloud_firestore and potentially other plugins.
This is my setup :

cloud_firestore: 0.13.4
firebase_auth: 0.15.4

and :

dependency_overrides:
  firebase_core: 0.4.4

Build gradle (Snapshot)

 dependencies {
        classpath 'com.android.tools.build:gradle:3.5.0' 3.5.3
        classpath 'com.google.gms:google-services:4.3.3'

        classpath 'com.google.firebase:firebase-crashlytics-gradle:2.0.0-beta02'
    }

and my build.gradle in Android/app :
dependencies {
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'androidx.test:runner:1.1.1'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.1.1'
    implementation 'com.google.firebase:firebase-analytics:17.2.2'

    implementation 'com.google.firebase:firebase-crashlytics:17.0.0-beta01'
}

This is CRITICAL. I cannot release to the PLAYSTORE with this issue.

Any updates?

This happens to me when running multiple transactions.

Try not putting things unrelated with transaction inside it, it actually solved my issue.

I made the Transaction function non-async (chained futures using then instead) and it solved this problem for me. Eg. changed this:
Firestore.instance.runTransaction((Transaction tx) async {       DocumentSnapshot recipeeSnapshot = await tx.get(recipee.reference);       if (recipeeSnapshot.exists) {         await tx.update(recipee.reference, <String, dynamic>{           'in_favorites_of': FieldValue.arrayUnion([userReference]),         });       }  })
into this:
Firestore.instance         .runTransaction((Transaction tx) {           return tx.get(recipee.reference).then((recipeeSnapshot) {             if (recipeeSnapshot.exists) {               return tx.update(recipee.reference, <String, dynamic>{                 'in_favorites_of': FieldValue.arrayUnion([userReference]),               });             }           });         })

I just noticed that the example on running transactions on the official readme uses an async transaction, I'm not sure if this is the best way to do it since concurrent transactions with async will cause this crash. Eg. tapping a button very fast that triggers the same transaction.

I made the Transaction function non-async (chained futures using then instead) and it solved this problem for me. Eg. changed this:
Firestore.instance.runTransaction((Transaction tx) async { DocumentSnapshot recipeeSnapshot = await tx.get(recipee.reference); if (recipeeSnapshot.exists) { await tx.update(recipee.reference, <String, dynamic>{ 'in_favorites_of': FieldValue.arrayUnion([userReference]), }); } })
into this:
Firestore.instance .runTransaction((Transaction tx) { return tx.get(recipee.reference).then((recipeeSnapshot) { if (recipeeSnapshot.exists) { return tx.update(recipee.reference, <String, dynamic>{ 'in_favorites_of': FieldValue.arrayUnion([userReference]), }); } }); })

This did not work for me. I tried to set the transactions to be non-async, but running the transactions simultaneously from two different devices still would crash one of them.

I'm having the same issue.  Just a thought, but should we try putting await in front of the transaction call?  Like this:
await Firestore.instance.runTransaction((Transaction tx) async { DocumentSnapshot recipeeSnapshot = await tx.get(recipee.reference); if (recipeeSnapshot.exists) { await tx.update(recipee.reference, <String, dynamic>{ 'in_favorites_of': FieldValue.arrayUnion([userReference]), }); } })

I am also having the same issue when I try to run the same transaction simultaneously on two android devices. It crashes on one of the android device whose transaction starts a little later than that of other.
E/AndroidRuntime(24675): Process: com.toodle, PID: 24675 E/AndroidRuntime(24675): java.lang.RuntimeException: An error occurred while executing doInBackground() E/AndroidRuntime(24675):        at android.os.AsyncTask$3.done(AsyncTask.java:354) E/AndroidRuntime(24675):        at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:383) E/AndroidRuntime(24675):        at java.util.concurrent.FutureTask.setException(FutureTask.java:252) E/AndroidRuntime(24675):        at java.util.concurrent.FutureTask.run(FutureTask.java:271) E/AndroidRuntime(24675):        at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245) E/AndroidRuntime(24675):        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)       E/AndroidRuntime(24675):        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)       E/AndroidRuntime(24675):        at java.lang.Thread.run(Thread.java:764) E/AndroidRuntime(24675): Caused by: java.lang.AssertionError: INTERNAL ASSERTION FAILED: A transaction object cannot be  used after its update callback has been invoked. E/AndroidRuntime(24675):        at com.google.firebase.firestore.util.Assert.fail(com.google.firebase:firebase-firestore@@21.3.0:46) E/AndroidRuntime(24675):        at com.google.firebase.firestore.util.Assert.hardAssert(com.google.firebase:firebase-firestore@@21.3.0:31) E/AndroidRuntime(24675):        at com.google.firebase.firestore.core.Transaction.ensureCommitNotCalled(com.google.firebase:firebase-firestore@@21.3.0:246) E/AndroidRuntime(24675):        at com.google.firebase.firestore.core.Transaction.lookup(com.google.firebase:firebase-firestore@@21.3.0:81) E/AndroidRuntime(24675):        at com.google.firebase.firestore.Transaction.getAsync(com.google.firebase:firebase-firestore@@21.3.0:191) E/AndroidRuntime(24675):        at com.google.firebase.firestore.Transaction.get(com.google.firebase:firebase-firestore@@21.3.0:228) E/AndroidRuntime(24675):        at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(ClouE/AndroidRuntime(24675):        at io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(CloudFirestorePlugin.java:608) E/AndroidRuntime(24675):        at android.os.AsyncTask$2.call(AsyncTask.java:333) E/AndroidRuntime(24675):        at java.util.concurrent.FutureTask.run(FutureTask.java:266) E/AndroidRuntime(24675):        ... 4 more W/OPDiagnose(24675): getService:OPDiagnoseService NULL D/OSTracker(24675): OS Event: crash

Despite what others are saying here, such as :-

Dont use await on runTransaction
Avoid unrelated TX code

etc - I'd just like to add that TX worked completely for me for pretty much most part of 2019. This included use of BatchWrites & runTransaction and using await on a runTransaction

The proper way one should be doing things

Furthermore, I used TX heavily in the app I am writing for both iOS and Android and worked completely in offline mode.
Additionally - worked concurrently across multiple disparate devices and platforms.
One device was saving (say) 400 documents and another device was deleting or editing some of those documents. This all happened without issue.
Now in 2020 - it Seems Cloud Firestore  and/or Firebase core or another dependent plugin- has brought with it regression issues.
To repeat - my issues only present itself when an ANDROID client attempts to write a large batch (100+ documents) and then looses signal during the TX.
One thing I have noticed, if you extend the DEFAULT TX TIMEOUT - this dramatically improves the TX writing and there is a higher percentage of your TX completing rather than you experiencing the

A transaction object cannot be used after its update callback has been invoked.

error
I believe there is a mismatch between Firebase core, Cloud Firestore & Firebase Auth and do recall that I temporarily fixed this problem by changing versions from 1 of the above.
Since there has been nobody from the  official Firebase or Flutter  team commenting on this issue in the last 3 months , I expect this to be quietly swept under the carpet for the rest of the year.....

Experiencing the same issue but only on Android. Either physical or emulator. It just crashes. On iOS there's no issue in either physical device or emulator.

My current workaround is to use wrap the calls with a connectivity checker (I'm using data_connection_checker) before making the transaction calls.
Still a pain though, definitely looking forward to a patch

Urgently need an update

I just noticed that the example on running transactions on the official readme uses an async transaction, I'm not sure if this is the best way to do it since concurrent transactions with async will cause this crash. Eg. tapping a button very fast that triggers the same transaction.

do you have crashes when 2 devices execute transaction at the same time after you changed to .then() ? This problem is a pain

Here's a snippet of my code:
It only crashes on Android when more then one device run the transaction at the same time. I've tried Android-Android and Android-iOS.
DocumentReference orderNumberDocument = Firestore.instance.collection(orderNumberPath).document(orderNumberDocumentId);
    try {
      await Firestore.instance.runTransaction((transaction) async {
            DocumentSnapshot freshSnapOrderNumber = await transaction.get(orderNumberDocument);
            int newOrderNumber;
            if (freshSnapOrderNumber.exists) {
              newOrderNumber = freshSnapOrderNumber['$orderNumberFieldName'] + 1;
              await transaction.update(freshSnapOrderNumber.reference, {
                '$orderNumberFieldName': newOrderNumber,
              }).catchError((e) {
                print('Order Number Update Failed: $newOrderNumber');
              }).whenComplete(() {
                print('Order Number Update completed: $newOrderNumber');
              });
            } else {
              newOrderNumber = 1;
              await transaction.set(orderNumberDocument, {
                '$orderNumberFieldName': newOrderNumber,
              }).catchError((e) {
                print('Order Number Set Failed: $newOrderNumber');
              }).whenComplete(() {
                print('Order Number Set Completed: $newOrderNumber');
              });
            }
    } catch (e) {
      print('Try catch failed: $e');
      rethrow;
    }

Same issue here. This actually happens with both iOS and Android. Live devices and Simulators.
Note as per https://github.com/FirebaseExtended/flutterfire/issues/1969#issuecomment-625882372

You must encapsulate your runTransaction with an await
Issue is related to the Transaction timing out and the internal assertion being raised rather than a PlatformException being thrown which we can trap.

Remember - transactions should :
A. Fail when in OFFLINE mode
B. If the TX is repeated 5 times and doesnt complete
C. If it times out
This issue now occurs on both iOS and Android and the assertion now takes precedence on A-C which is where the bug is.
What does work :

As a short term FIX - Increase the timeout on your transaction. This helps where long/complex transactions require more than 5 seconds to run.

What always fails :
Run your TX code code on your device/simulator with NO INTERNET - internally, your TX will be repeated 5 times, then turn on your internet. Your TX will fail and you will get the assertion error.
Note - to simulate the issue above, you need to have (say) a routine that inserts/delete lots of documents (try 20,30,50 etc) within a Single TX.
3 Months on and no Fix ???

Problem persists for me in version 0.13.6

I am facing the same issue when running the multiple transactions on the same document.

I'm seeing the same issue when a device is offline.
The last version I've tried that's without the error is 0.12.10 and the first one where it fails is 0.12.11.
As far as I can see, the commit https://github.com/FirebaseExtended/flutterfire/commit/5076f045c5b01798ddb4f62ffdb031afbc90ff03 added in version 0.12.11 does not have relevant changes in the plugin but it changes version of com.google.firebase:firebase-firestore from 19.0.0 to 21.3.0.
One of the changes introduced in the new version is the new hardAssert that we're hitting: https://github.com/firebase/firebase-android-sdk/commit/dd692603b6c8d4a4b7b2715b3925de8eded85ea6

private void ensureCommitNotCalled() {
hardAssert(
!committed,
"A transaction object cannot be used after its update callback has been invoked.");
}

same issue here here

I am now hitting this problem in iOS as well as Android.
I previously thought this was a problem only in Android in OFFLINE mode but thats not the case.
Now the situation in iOS crashes my app when I set a timeout of 5 seconds and try and remove a large number of documents as part of a TX. So If I try and delete 50 documents in a collection and then try and remove the parent document it crashes.
In Android - the error is different, repeating the same test I get a failed TX with the error :
'Every document read in a transaction must also be written'
If I increase the timeout to say 60 seconds then both iOS and Android work without any issue under this test.
Its worrying that nobody has been assigned to look at this severe issue - Flutter is nothing without a stable backend . There is no point making Flutter look pretty if I can save data consistently !

Hi All - I can confirm this is a problem and is being fixed as part of #2582
On Android at least, I have recently refactored a lot of the transaction code to handle various user issues. Work is still in progress on the iOS side of things.
The overall observations are:

Transaction retries were not being handled.
The commands (set, update, delete) were being sent with fire-and-forget as Futures. These should be batched up locally and sent once the TransactionHandler logic is complete.
Any errors thrown by the user were being swallowed into a generic "Exception".
Primitive values returned from the TransactionHandler were being returned from the runTransaction promise, however any non-primitive values (such as a DocumentSnapshot) were causing a crash (since they cannot be transferred to native and back).

I'd say for now, try and stick with WriteBatches & FieldValue support until the stable/tested update lands.

@Ehesp When you say :
I'd say for now, try and stick with WriteBatches & FieldValue support until the stable/tested update lands.
Unfortunately - during my tests - I'd just like to add that Transaction support whether its via :
runTransaction (Transactions) or
BatchedWrites
are broken and BOTH exhibit the behaviour discussed in this thread. Thus if we need to have the benefit of transactions when dealing with documents, collections & collection groups - if the primary transaction api's in Firebase (Transaction & BatchWrites) are broken then are you saying we should implement our own internal transaction handling by making use of FieldValue.serverTimestamp() until this issue is fixed ?

@sallypeters If I increase the timeout to say 60 seconds then both iOS and Android work without any issue under this test.

That's correct, the timeout is there to protect yourself and the OS. It defaults to 5 seconds, for each transaction attempt. Upping the limit is fine for a large volume of transaction operations.
I'm also not too sure about write batch, I feel that's a separate issue as they're both totally different implementations.

@Ehesp
Setting a very high timeout value may help some apps based on their operating context but other apps may need immediate notification when offline or a transaction implicitly fails - if a very high timeout is set, these last two conditions will not be met until the timeout ends which is not practical.
This issue that we are all facing is actually huge since it prevents firebase data-centric apps being deployed to the various stores.
If at all possible, can we say with certainty when this regression issue crept in so that we can all rollback to using a more stable version of the firebase API's that offer a seamless error free transaction experience across both iOS and Android
For my use case, I need to know the most stable version of cloud firestore/firebase core  that will work with Firebase API's for :
Cloud firestore
Cloud functions
Firebase_auth
Firebase_core
Firebase_storage
Google_sign_in
Firebase_remote_config

Lastly - This issue has been around since Nov/Dec 2019 -  I consider this to be an urgent issue,  yet  I don't see any tags/labels here stating its severity ? Can you therefore advise what the community needs to do to bump this up the triage process so that it gets looked at much sooner ?

Interestingly I'm not actually able to get transactions to abort when offline (using disableNetwork), it will always trigger which is frustrating to test.

Lastly - This issue has been around since Nov/Dec 2019 - I consider this to be an urgent issue, yet I don't see any tags/labels here stating its severity ? Can you therefore advise what the community needs to do to bump this up the triage process so that it gets looked at much sooner ?

We have this tracked internally and has the relevant labels. In-fact, transactions have already been reworked as part of #2582 on Dart & Android, we're currently working through the iOS side of things.
There's more issues which have to be resolved with transactions on-top of this, such as being able to bail out with errors, handle these on Dart and also return non-primitive values from the transaction. The only one I'm unsure of is properly testing the offline behaviour (since disableNetwork doesn't seem to effect transactions).

@Ehesp
Pre Oct/Nov 2019 - Transaction support worked well in both iOS and Android. When offline, a transaction would always (and rightly so) fail and one would be able to capture the exception. The API for transactions always stated that :
Transactions will fail when the client is offline.
This is no longer the case which means if a users device is fluctuating between online/offline and a transaction is in-flight,  there is now, no longer any mechanism for an app to gracefully handle these scenarios - the app just crashes (under Android) when the device comes back on line.
I suspect a fix for what we are experiencing is actually many months away, and if we are lucky probably we will get by the end of the year - so, coming back to my previous question , it would be great if you can help identify where the regression error crept in so that we can all rollback to a more stable build.
 If at all possible, can we say with certainty when this regression issue crept in so that we can all rollback to using a more stable version of the firebase API's that offer a seamless error free transaction experience across both iOS and Android

@Ehesp Do you have any info regarding @alexda12 last comment - I would also like to know which version of the Firebase plugins work so that we can downgrade to that  version.

I am so glad I found this thread and didn't put my fist through my monitor. The Transaction issues have rendered my social app unusable over the past month. I have tried various workaround with no success. I cannot figure out where to rollback to for stable transactions. This isn't just an issue to "sweep under the rug", this is a legitimate show stopper for our app development. My app can't run more than a minute of basic usage without crashing.
If a fix isn't coming soon, could you at least make the issue more known? As a developer, for weeks I thought I was doing something wrong. I was prepared to throw away my entire project and even fathomed building my own backend because of this.
Asking us to avoid using transactions is like asking us to take three wheels of our car.

@Ehesp Firstly - can you shed some light on what was asked by @alexda12 a few days back please - I'm certain this information is critical in developers deciding whether to park development with Flutter/Firebase or to persevere and attempt to roll with the current pain points of this severe regression issue.
Secondly , as per your message stating as a workaround :
I'd say for now, try and stick with WriteBatches & FieldValue support until the stable/tested update lands
Adopting Firebase batches aka batch Writes will not help the majority of transaction based code since READS will be paramount especially when dealing with complicated queries, collection groups and transactions that span multiple documents and collections.
This issue has actually be around since late Aug 2019. From my analysis - It originally surfaced in Cloud Firestore 0.13.0+1.
0.13.4 actually fixed the crashing in Android in Offline mode but then there was another regression issue with Firebase_core and 0.4.4 was meant to fix this issue along with another regression issue with Firebase_auth 0.15.4. Unfortunately - the whole Firebase API eco system is a mess with respect to versioning and dependencies. Generally , a developer might take the approach to always upgrade to the latest version of the FlutterFire SDK's but in my experience, I've found this counterproductive - and my advice to any Flutter developer reading this thread is to stay put with what you have. If your app works and you dont have any bugs in any of the standard Flutter/Firebase API's and you dont have a compelling reason to upgrade , then stay put. Its not worth the headache and regression issues that you will inevitably experience. I have not updated to Flutter 1.17.2. I am still on 1.12.13 hotfix 5. It works, I am soon to release my app (have been waiting 8 months for a for this TX issue to be resolved and then I can release) and I really dont have the time to go through the pain again of upgrading Flutter (1.78 to 1.9x was a major headache) - So will either upgrade Flutter after I go live or potentially go back to Xamarin which I didnt want to do (and  investigate Xamarin MAUI).
Regarding this TX issue - everyone might want to try and go back to 0.12.10+2 or 0.12. Currently I am having some success with this version.

@MsXam you're right about 0.12.10+2.  I downgraded and I'm no longer having any transaction issues.  Thanks!
Any potential downside to downgrading to that low a version?  I see that 0.12.10+2 was released in November.

@mohisham I have spent a considerably amount of time going back for the past year of updates/changes on the FlutterFire plugins (Storage, Auth, Firestore etc) to try and ascertain at what point the transaction handling was broken and can now say with some certainty that adopting 0.12.10.x would provide better stability then what we are currently seeing in the present versions.
If you dont need Mac OS or WEB Support, or you do not require comprehensive Querying capabilities then I would advise moving past this version for pretty much most of this year unless other dependent  FlutterFire plugins bump up their minimum dependent versions of Cloud_firestore above 0.12.10.x.
As a sidepoint, I'm sure everybody is doing this but so that we are not locked into a particular vendor back-end , it would be prudent to construct your backend code such that you can easily swap Firebase/Firestore for say AWS or AZURE should the timeframe for Invertase developers to fix/restructure/refactor  the existing FlutterFire plugins exceed your expectations - they have been somewhat quiet to numerous requests for clarification so I think its safe to say that this current problem will not be effectively fixed anytime soon.
I'm currently testing Amazon DynamoDB which so far is yielding great results/performance and is more mature than Cloud Firestore and stable and so the issues we are experiencing with Cloud Firestore are definitely not present in DynamoDB.

Firstly - can you shed some light on what was asked by @alexda12 a few days back please - I'm certain this information is critical in developers deciding whether to park development with Flutter/Firebase or to persevere and attempt to roll with the current pain points of this severe regression issue.

they have been somewhat quiet to numerous requests for clarification so I think its safe to say that this current problem will not be effectively fixed anytime soon.

We don't have much history with this library, so I'd be guessing (unless I spend a bunch of time sifting through commits/code) to give an exact version.
ETA on a Core/Firestore/Auth usable update is 4-6 weeks. It will probably be as a dev release as there are large changes we'll need to make sure devs can work with before we ship as a full release.
The plan is also to have the other plugins be compatible with these changes, even though they'll be getting QOL updates later.

@MsXam
Thanks for your tip about downgrading version. There is no more crash in 0.12.10+2 when trying to reload transaction again.
Unfortunately, it still doesn't work what I expected.
I thought if transaction failed, it rollback and retry to run transaction section fully.
But, as I checked, rollback is working well, but running transaction is stopped in getting document.
(ex. transaction.get(ref))
Anyway, it doesn't matter in my app flow.
So, I solved this problem temporarily with your help.  Thanks.

@butyear
The version 0.12.10+2 should address the following issues and provide stability for BatchWrites and runTransaction API calls :-

If a client (Android or iOS) is offline - the TX will immediately fail and a PlatformException can be caught. This is the correct behaviour.

If your TX performs reads which are used in updates/deletes and your reads then change - YOUR ENTIRE TX will be re-executed for upto 5 retries. If the TX still doesn’t complete within 5 retries, you can catch a PlatformException. This is the correct behaviour.

If your TX handling involves >500 documents, your TX will fail. This can be captured in a PlatformException. This is the correct behaviour.

If your TX uses the timeout parameter and your TX does not complete within this time, your TX will fail and a PlatformException can be caught. This is the correct behaviour.

If your TX performs a mixture of reads, updates, deletes, inserts etc and you mix the reads throughout your TX code. Your TX will fail. You can catch the PlatformException.  This is the correct behaviour.

Despite conflicting information regarding the correct usage of runTransaction etc . You need to always AWAIT the runTransaction. Failure todo so can cause potential race conditions when the same TX  (that is in-flight) is re-executed again from the client because of rebuilds that are out of your control.

Upfront caching, querying, getting snapshot information or collection group info should be done outside of the runTransaction. Unless you want these operations to be PART of the READ phase for a TX , it is best to place outside of the TX for performance and potential TX failures. This is the correct behaviour.

BatchWrites are faster than code wrapped in a runTransaction. If you have no need for READS, restructure your code in a BATCHWRITE. BatchWrites never FAIL when a client is offline and will always succeed. When a client is back online, the local TX cache will be applied on Cloud Firestore.

If your TX size is >10MiB, it will; fail. If you are writing deep-nested complex transaction code that can potentially encompass >1 and <500 documents - you may want to write the equivalent of a sizeOf() so that you can detect if your TX will exceed this limitation. Remember fieldnames will also add to the limitation so its best you structure your Cloud Firestore schema such that very long field names are not used (They will also cost you more money in the long run). If your TX code exceeds 10<MiB , you can capture the PlatformException, parse this and look for default strings that will enable you to provide a more user-friendly message. This is the correct behaviour.

Finally - ensure your document writes are limited at most to 1 per second. Anything more than this will result in a failed TX which can be caught via PlatformException. This is the correct behaviour.

Example formatting code for PlatformException :
....
on PlatformException catch (pe) {
      String mess;
      if (await CommonsHelper.isOffline()) {
        mess = 'Are you offline ?';
      } else {
        mess = 'Your custom message ....';
      }
      var formatted = formattedPlatformException(pe);
      if (formatted != null) {
        mess = formatted;
      }
     /// Can be any custom message that gets displayed on the client
      tupleReturned = Tuple2('TX failed.\n$mess', false);
    } on Exception catch (e) {
     /// Can be any custom message that gets displayed on the client
 tupleReturned = Tuple2('TX failed\n${e.toString()}', false);
    }
    return tupleReturned;
....

And FormattedPlatformException
  /// Takes a PlatformException and creates a friendlier message
  String formattedPlatformException(PlatformException pe) {
    if (pe != null) {
      String code = pe.code == null ? '' : pe.code.toLowerCase();
      String message = pe.message == null ? '' : pe.message.toLowerCase();
/// Check for various codes here and provide a friendlier message ...
      if (code == '3' &&
          message.contains(
              'every document read in a transaction must also be written in that transaction')) {
        return Strings.tooManyRowsSelected;
      }
      if (code == '14' && message.contains('dns resolution')) {
        return Strings.operationFailedNoInternet;
      }
      if (code == '3' && message.contains('maximum 500 writes'))
        return Strings.txDocumentLimitReached;
    }
    return null;
  }

@MsXam
In my case, number 2 condition is not working well.
Here is a simplified sample code.
`
// Here is the scenario.
// Read A, B user, and check isRunning.
// If A, B is not running, do some related task, and change isRunning to true in transaction.
// Then if C user is trying to run with B, can't connect because B is already running with A.
Firestore.instance.runTransaction((transaction) async {
// read document using transaction.get
DocumentSnapshot aDocumentSnapshot = await transaction.get(aDocRef);
DocumentSnapshot bDocumentSnapshot = await transaction.get(bDocRef);
// Point 1 : Can't reach here after transaction error.

User a = User.fromJson(aDocumentSnapshot.data);
User b = User.fromJson(bDocumentSnapshot.data);

if (a.isRunning == false && b.isRunning == false) {
    roomName = makeRoomName(_myId, yourId);

    // give delay for testing transaction
    // !! while delaying, change user B's isRunning to "true" in firestore console page.
    // it's like another user is connected with B while A is trying to connect with B.
    await Future.any([
        Future.delayed(const Duration(seconds: 3))
    ])

    // task 1
    transaction.set(~~);

    // task 2
    transaction.delete(~~);
    transaction.delete(~~);

    // task 3
    await transaction.update(aDocRef, { 'isRunning': true });
    await transaction.update(bDocRef, { 'isRunning': true });
}

});`
In this case, I changed isRunning value to true in firestore console after getting value for making transaction error intentionally.
Then, after task 3 failed, task1 and task2 are rolled-back. And runTransaction starts again.
But at Point 1, transaction stopped and can't reach task1~3 again.
I don't know why it works like this.
I'm thinking about simulating this flow in java or other platforms.
I wanna know if it is only cloud_firestore library's problem or not.
Or am I using this incorrectly?

@butyear
In your context, the potential issue you are seeing is because of incorrect use of Cloud Firestore API ...
You need something like this :

@MsXam
Thanks for your kind explanation.
As you said, of course I set docRef outside of transaction like below. (about No.4)
'
DocumentReference aDocRef = userRef.document(aDocId);
DocumentReference bDocRef = userRef.document(bDocId);
Firestore.instance.runTransaction(~~~ ...)
'
But I have a question about No.5
If I don't use "transaction.get", then doesn't transaction work wrong?
If I use just aDocRef.get, then when aDoc data is changed from other user, transaction doesn't occur failure.
Even other user changed aDoc's data, this transaction code over write aDoc's data without any failure.
So, if you are interested in talking about this more, let me make a real working sample code now and share it.

Hi everyone. So, I rolled back to 0.12.10+2 and although my app doesn't crash anymore if I fire 2 transactions one on iOS and one on Android physical devices at exactly the same time the Android device fails to get its transaction persisted in Firebase. Which I think it's even worse because I don't get any exceptions and me and the user are none the wiser. I rather let the app crash so the user knows something went wrong. I'm safeguarding his order so he'll see it's still there and will be able to resubmit. I haven't looked at all the code snippets posted yet. Maybe I'll find some wisdom there.

@ErnestoCuesy
From your description - this is what I would expect to happen apart from no exception being propagated back to the android client when its TX fails - but that could be down to your implementation .
If two users update the same document at exactly the same time - Are you expecting Cloud Firestore to deny one user access  , fail the tx and allow the other user 100% write access to the document ?
What actually happens is that in the case of any potential concurrent edits, Cloud Firestore will attempt to re-run the entire TX again but this time it will (based on how you have structured your tx code) attempt to get the latest documents so its working on the most uptodate data. It will attempt to do this 5 times and if the tx still finds its working with dirty data, the entire tx will fail. This is the correct scenario.
I suspect that your android client is indeed getting its data persisted but then the iOS client now gets the most uptodate document and overwrites the data persisted by the Android client. This can easily be proved amending your logic to update different parts of the document based on the client that is running the TX (Android/iOS) - then checking to see that iOS field has been updated and Android field has been updated after the TX completes etc ...
If you want your TX code to fail if the document its working on is dirty (Has been changed by another user) then you can provide this functionality yourself - this is an implementation issue and nothing to do with issues with Cloud Firestore.

@MsXam thank you for your comments. Interesting scenario you mentioned that the Android transaction is overwritten by the iOS client. I will test that. I'm still very new to Firebase but from my previous SQL knowledge I would expect the database to kind of queue the incoming transactions and process them serially as they are finished, but that's how I picture it in my head and it could well be a wrong assumption. It looks like more than one transaction can be processed concurrently, am I right? Then yes, I totally agree I would need to look at my logic and rewrite accordingly. Thanks again.

@MsXam
I have downgraded to the recommended version and can confirm BOTH Android & iOS work.
Many thanks for spending the time going through the various commits to establish a version that works.

@MsXam . Downgrading works. I no longer have the crash.
@Ehesp Setting a timeout to say - 5 seconds crashes an iOS or Android app when the TX doesnt complete within this time. Has this been identified as a bug also on your refactoring analysis - the docs state that a transaction that fails should ALWAYS return an error code. This currently is not happening on both platforms.

@bpaul7101 added a test case on that on the rework:

Just curious has this issue been addressed as part of the flutterfire roadmap ?  https://github.com/FirebaseExtended/flutterfire/pull/2913

Hey everyone 👋 , as part of our on-going work for #2582, this has been resolved in our Firebase Firestore rework (#2913), transactions has had a massive rework as unfortunately it was fundamentally broken in a lot of places, points specifically in relation to this issue (but there's many others):

transactions will now bubble errors through to Dart should it fail on native (rather than it crashing).
the default timeout has been increased to 30 seconds, up from 5.
timeout behaviour is now functioning correctly on iOS (previously on timeout in iOS nothing happened as the return value from dispatch_semaphore_wait was completely ignored).
iOS no longer returns a result twice.

This has now been merged into master. We'll look at publishing some prereleases in the next few days. Thank you

@Salakar Are you sure this is in Stable ? I have just tried to see if this has been fixed and I still get the same issue as discussed here https://github.com/FirebaseExtended/flutterfire/issues/1969#issuecomment-599065549
i.e I get a crash in Android when device toggles between offline and online and there are transactions already running ....

@Salakar Are you sure this is in Stable ? I have just tried to see if this has been fixed and I still get the same issue as discussed here #1969 (comment)
i.e I get a crash in Android when device toggles between offline and online and there are transactions already running ....

Nope it's not in stable;

This has now been merged into master. We'll look at publishing some prereleases in the next few days. Thank you

@Salakar , sorry I meant to say master  ...

Every time I click the button to execute the transaction when I'm offline, the application crashes. Can anyone tell me why? My code is as follows:
import 'package:cloud_firestore/cloud_firestore.dart';
import 'package:mobx/mobx.dart';

part 'plantao_controller.g.dart';

class Controller = ControllerBase with _$Controller;

abstract class ControllerBase with Store {
  Future<bool> pegarPlantao({cpf, hospital, setor, dia, horario}) async {
    Map<String, dynamic> mapa = {};
    if (horario == '00:00-06:00') {
      mapa['00:00-06:00'] = cpf;
    } else if (horario == '06:00-12:00') {
      mapa['06:00-12:00'] = cpf;
    } else if (horario == '12:00-18:00') {
      mapa['12:00-18:00'] = cpf;
    } else if (horario == '18:00-00:00') {
      mapa['18:00-00:00'] = cpf;
    }
final ref = Firestore.instance
    .collection(hospital)
    .document('Escala 2020')
    .collection(setor)
    .document(dia);

final doc = await Firestore.instance
    .runTransaction((t) {
      t.update(ref, mapa);
    })
    .then((value) => true)
    .catchError((onError) => false);

    return doc;
  }

  Future<bool> passarPlantao({cpf, hospital, setor, dia, horario}) async {
    Map<String, dynamic> mapa = {};
    if (horario == '00:00-06:00') {
      mapa['00:00-06:00'] = '';
    } else if (horario == '06:00-12:00') {
      mapa['06:00-12:00'] = '';
    } else if (horario == '12:00-18:00') {
      mapa['12:00-18:00'] = '';
    } else if (horario == '18:00-00:00') {
      mapa['18:00-00:00'] = '';
    }

final ref1 = Firestore.instance
    .collection(hospital)
    .document('Escala 2020')
    .collection(setor)
    .document(dia);

final doc = await Firestore.instance
    .runTransaction((t) {
      t.update(ref1, mapa);
    })
    .then((value) => true)
    .catchError((onError) => false);

    return doc;
  }
}

any updates ?


event.gesture not defined

When i access my page from my localhost server everything behaves as expected, but when i deploy exactly the same configuration on a server, the object event.gesture is undefined. Instead the gesture object is available in the event.originalEvent object.

Uncaught TypeError: Cannot read property 'stopDetect' of undefined because of event.gesture.stopDetect()
This is still active issue

+1 I get this issue with IE10 on Win8
On an  tag event.gesture == undefined (occasionally)

use event.gesture.scale


Test Jupyter Notebook extension onboarding as a "fresh" user

We want to test the Jupyter Notebook extension onboarding and see if we can use some of their techniques inside of our own extension.

Here are my notes on the process of onboarding for the Jupyter Notebook extension:
Installing the extension and opening it in an empty project gives us empty views. None of the actions shown work.

Opening any random project will also give us the same result.
Only after creating a ipynb file and running it, we get an install prompt for the currently selected interpreter.

Clicking install will install all the necessary python packages and result in the cell or file being able to run.
https://user-images.githubusercontent.com/3683420/203850876-280586a2-a9a9-4c4f-9d24-8b64f9261459.mov
Clicking cancel will result in an error message.

This concludes any onboarding I was able to find for the extension.
In my opinion this onboarding process is more about installing everything needed than setting up a project for you. It does not tell you how to use the extension either. I would compare it more to our “Setup the Workspace” workflow.
We could apply the same method to initialize a project (installing dvc), but for creating configuration files and setup everything needed, we’d need to find inspiration elsewhere.
What do you think @iterative/vs-code ?

@sroy3 thanks for the research 🙏 Yes I meant this as one of the first steps in the onboarding flow, not as a complete solution.


Could not connect to iOS 11 device

Hello,
I use version 1.7.1. It works well with iOS 10.
When I plug an iOS 11 device, I have this error in console :
Could not connect to lockdownd. Exiting.: No error
Unable to attach your_device_uuid inspector

you need a fresh version of the utility, it is available here


Add analytics tool to production frontend

Is your feature request related to a problem? Please describe.
We should consider adding an analytics tool (e.g. Google analytics, Mixpanel, etc) to Nest production version when it's ready.
Describe the solution you'd like
Identify right tool and implement its setup/configuration.

I would love to work on this cc @arkid15r

@arkid15r i would like to implement this. I will add google analytics via Google tag manager. I have previously done it in my projects too.


efficience about data augmentation on Large graph

Hi,
I'm interested in self-supervised learning on the graph and GraphCL is an excellent work that combining self-supervised learning with augmentation. However, I'm also curious about its usage in large graphs such as knowledge graph and so on. May I ask you about the suggestion on the augmentation operation on the knowledge graph? Because in the way of GraphCL, it needs 4 GNN encoders at the same time per epoch. Thanks a lot in advance~

Hi @Wjk666,
Thanks for your interest. For NodeDrop, EdgePert and AttrMask augmentations, complexity should be O(K) (where K is the augmented number, e.g. the nodes dropped in NodeDrop), thus it is OK to scale up on larger graphs. For Subgraph the complexity might be higher since there is a while loop in it, so when comes to too large graph, I think you might consider updating the implementation a little bit.
Because in the way of GraphCL, it needs 4 GNN encoders at the same time per epoch.
Actually in GraphCL it only requires 1 GNN encoder, propagate for twice (2 augmented views). Things might be some different when comes to your case.

@yyou1996 Thanks a lot for your advice and suggestion, I think I have to check my code.


Git commit

This PR is to add the enhancement in #763

This is working for single file format, commit to master.  Will add additional options in a new PR.

Why remove the yarn.lock?


Template.Compile fails

Hello,
I have problem with Template.Compile() method.
My template looks like:
@foreach (var event in<EMAIL_ADDRESS>That compilation works in Console Application and in one my test Windows Service, but fails in another Windows Service.
(but e.g. simple template like: @Model.Name works)
The generated source code is the same, but in Windows service I get TemplateCompilationException with many errors ( "} expected", "Type expected", "Invalid token...", etc).
Is possible that I'm missing some dependencies or is there some conflict with other references?

not use foreach. you can use forto do .


bt_le_adv_start() with sd_len=0

Describe the bug
Calling bt_le_adv_start with sd_len=0 and non-NULL sd will act as if scan response exists.
Expected behavior
The function shall check if !sd || !sd_len instead of only !sd || !sd_len
Additional context
Add any other context about the problem here.

@paulgavrikov I assume you're filing this against 1.13? The code has substantially changed since then, so the description doesn't really make sense when looking at the current code.

Anyway, this seems like nonsense behavior from the application. All the current (master branch) does in this case is that it clears the scan response data. There are no buffer overflows or anything like that. So I'm not even sure whether this qualifies as a bug.

@jhedberg yes, sorry I still wasn't able to check out 1.14. Problem is if you handle your advertising data dynamically and switch from scan response to no scan response you can do that easily by setting sd_len=0 but zephyr will then still use BT_LE_SCAN_IND .

@paulgavrikov ok, so that's a use case we haven't considered. I'm going to downgrade this to a feature request, but I do agree that we should try to find a solution to this.

@paulgavrikov I'm looking again at existing master, and it seems to me like it should already behave like you want. Also note that we have new bt_le_adv_update_data() API which might suite your purpose better.

@jhedberg Almost perfect there except:
I think changing the !sd checks to !sd_len is a much safer way.

I think changing the !sd checks to !sd_len is a much safer way.

@paulgavrikov perhaps, though all the branch does is calls sd_has_name() and that function will not do anything if sd_len is 0. Anyway, if you feel strongly about this feel free to submit a PR :)

@jhedberg Not that strongly :P


Boost failed msvc.archive ... error when running make setup

CARLA version: 0.9.14
Platform/OS: Windows 10 64 bit
Problem:
I tried to build carla dependencies using make setup, but always got an error on boost like this:
...
compile-c-c++ build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\numpy\scalars.obj
08:54:12:497	    scalars.cpp
08:54:12:508	    compile-c-c++ build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\numpy\ufunc.obj
08:54:12:509	    ufunc.cpp
08:54:12:608	    msvc.archive build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\libboost_numpy311-vc142-mt-x64-1_80.lib
08:54:12:608	    link: extra operand '/out:build\\boost\\bin.v2\\libs\\python\\build\\msvc-14.2\\release\\link-static\\python-3.11\\threading-multi\\libboost_numpy311-vc142-mt-x64-1_80.lib'
08:54:12:608	    Try 'link --help' for more information.
08:54:12:741
08:54:12:741	            if exist "build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\libboost_numpy311-vc142-mt-x64-1_80.lib" DEL "build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\libboost_numpy311-vc142-mt-x64-1_80.lib"
08:54:12:741	            call "build\boost\bin.v2\standalone\msvc\msvc-14.2\msvc-setup.bat"  >nul
08:54:12:741	     link /lib /NOLOGO  /out:"build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\libboost_numpy311-vc142-mt-x64-1_80.lib" "build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\numpy\dtype.obj" "build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\numpy\matrix.obj" "build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\numpy\ndarray.obj" "build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\numpy\numpy.obj" "build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\numpy\scalars.obj" "build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\numpy\ufunc.obj"
08:54:12:742
08:54:12:742	    ...failed msvc.archive build\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi\libboost_numpy311-vc142-mt-x64-1_80.lib...
08:54:12:742	    ...skipped <pG:\all-project\thesis-project\campus-av\dependencies\carla-source\Build\boost-1.80.0-install\lib>libboost_numpy311-vc142-mt-x64-1_80.lib for lack of <pbuild\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi>libboost_numpy311-vc142-mt-x64-1_80.lib...
08:54:12:742	    ...skipped <pbuild\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi>libboost_numpy-variant-vc142-mt-x64-1_80-static-py3.11.cmake for lack of <pbuild\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi>libboost_numpy311-vc142-mt-x64-1_80.lib...
08:54:12:742	    ...skipped <pG:\all-project\thesis-project\campus-av\dependencies\carla-source\Build\boost-1.80.0-install\lib\cmake\boost_numpy-1.80.0>libboost_numpy-variant-vc142-mt-x64-1_80-static-py3.11.cmake for lack of <pbuild\boost\bin.v2\libs\python\build\msvc-14.2\release\link-static\python-3.11\threading-multi>libboost_numpy-variant-vc142-mt-x64-1_80-static-py3.11.cmake...
08:54:12:742	    ...failed updating 6 targets...
08:54:12:742	    ...skipped 18 targets...
08:54:12:743	    ...updated 16584 targets...
08:54:12:776
08:54:12:777	        -[install_boost]: [B2 ERROR] An error ocurred while installing using "b2.exe".
08:54:59:463	        -[install_boost]: Exiting with error...
...

Tools that Im using to produce that errors:

Visual Studio 2019 msvc 14.2
CMake
Make 3.81

After I analyze the errors after trying a lot of times with a lot of configurations (like changing using Visual Studio 2022 msvc 14.3 and changing my cmake variables, also changing the directory), I found that it sometimes can be successfully built but in occasional moments, I don't know what I did wrong at that time.

Hey, @thomiaditya Did you find a work around?


MFC samples are not linked correctly

When I click MFC samples, it redirects me to "Browse code samples" page.
In this page, I can see "This page was permanently redirected ..." on top.
The real problem is that I cannot find MFC example in this redirected page.
I cannot see MFC in Filtering by Products. Filtering by language C++ also does not show MFC related samples. Also searching with MFC related keywords (ex. View, Dialog, ListCtrl) does not show samples what I want.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6703184d-efb9-65e6-b9ef-31882e7e1e2b
Version Independent ID: 27d915fa-1a40-947e-05f0-fc9413c42ad4
Content: Visual C++ Samples
Content Source: docs/overview/visual-cpp-samples.md
Product: visual-cpp
Technology: cpp-language
GitHub Login: @corob-msft
Microsoft Alias: corob

I think I found MFC examples on https://github.com/microsoft/VCSamples
As you see, It's splitted into each VS versions and some of them seems to be outdated.
I'd suggest to create a page which links each MFC samples location.


Update card after download of single resource

Follow up of #568
At the moment when the download of the single resource has not finished the card is not updating. No thumbnail for the item is shown.

[ ] https://github.com/endlessm/kolibri-explore-plugin/pull/629

Potentially this is not an issue anymore when we have the thumbnails downloaded as part of the metadata. Not sure if there are any other consequences than the thumbnail not being displayed.

@erikos thanks for splitting this into a separate task.

Potentially this is not an issue anymore when we have the thumbnails downloaded as part of the metadata. Not sure if there are any other consequences than the thumbnail not being displayed.

Right. If we assume that thumbnails will be there, I can workaround by just setting the card to "available" in the frontend.

I managed to do this reactively (without any reloading) in the Search page. Adding the PR as a subtask. Next is the custom presentation.
https://github.com/endlessm/kolibri-explore-plugin/assets/83944/33cb2182-c4f1-4eb4-b6f9-1e2423440bd7

I'm still not sure why the nodes keep cached in the custom presentation, but I managed to workaround it in a separate PR.
So far I did Home, I still need to do this in 3 more views:

packages/template-ui/src/views/ListSection.vue
packages/template-ui/src/views/Section.vue
packages/template-ui/src/components/FilterResult.vue

Verified passed in Ladybird 6.15-346.
Windows issue: #641


Reorganize oss-artifacts-validators

Describe the feature you'd like to request
This is intended to be a lib. We should just make a root level lib directory and move this there.
Describe the solution you'd like
We should move this as a shared lib in lib
Describe alternatives you've considered
N/A

Done https://github.com/opensource-observer/oso/pull/1458


orElse javadoc

see #1872 #1873
PriorityQueue refactored as @paplorinc suggested

Codecov Report

Merging #1876 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #1876      +/-   ##
============================================
+ Coverage     98.07%   98.07%   +<.01%
- Complexity     5052     5053       +1
============================================
  Files            88       88
  Lines         11404    11405       +1
  Branches       1502     1503       +1
============================================
+ Hits          11185    11186       +1
  Misses          113      113
  Partials        106      106

Impacted Files
Coverage Δ
Complexity Δ

...ng/src/main/java/javaslang/collection/TreeSet.java
100% <ø> (ø)
169 <ø> (ø)
:x:

...ang/src/main/java/javaslang/collection/BitSet.java
99.42% <ø> (ø)
78 <ø> (ø)
:x:

...ng/src/main/java/javaslang/collection/TreeMap.java
96.17% <ø> (ø)
150 <ø> (ø)
:x:

...in/java/javaslang/collection/AbstractMultimap.java
95.55% <ø> (ø)
122 <ø> (ø)
:x:

.../main/java/javaslang/collection/PriorityQueue.java
98.66% <100%> (ø)
105 <2> (+1)
:white_check_mark:

Continue to review full report at Codecov.

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


Old format is not formatting the same as numeral

Hello! I'm trying to switch from numeral to numbro and i've encountered a problem.
When formatting like this
http://numbrojs.com/old-try-me.html?lang=fr-FR&value=12345&format=0%2C0.[000000]
It shows extra 0s, while formatting in numeral does not.
I have tried using the same format in this fiddle made by someone else.
http://jsfiddle.net/erbronni/19mLmekt/
Numbro with 12345 and 0.0[0000] returns "12 345,000000"
Numeral returns "12345"
Shouldnt Numbro oldformat work like Numeral?

V1 format is a hell, with a lot of corner cases, and we added so many options that it turns out to be quite unusable.
I can only advice you to use the v2 format where options are much more explicit.
(yet it's a bug, and I'll try to fix it asap)
@all-contributors please add @OvidiuBan  for bug

@BenjaminVanRyseghem

(yet it's a bug, and I'll try to fix it asap)

Is there any hope for this? I understand that v2 is a much more precise solution, but this appears to be the only issue preventing numbro from being a drop-in replacement for numeral (and there is simply way too much v1 in our codebase to consider refactoring everything).


Fix get user profile url

This PR removes the incorrect } at the end of the generated profile URL when access token is provided, as well as makes accessToken explicitly optional (typings only, no runtime impact).

Sorry, wrong commits. Opening a new one.


progressive-web-app

Please use the form below, leaving the prefilled data to help us. Thank you.
Page link: progressive-web-app
Document link: progressive-web-app.md
My Issue/Suggestion
add this link as a resource
https://medium.com/@mohamedbeemubeen/web-push-notification-for-progressive-mobile-apps-ad4b48241ba0

Hi Jason,
Thank you for you suggestion. The majority of this content is already explained in our first-party documentation.
If there are specific steps in your medium article that our docs lack that you think should be in them, can you suggest them here -- or better yet, stage a docs PR?
Connor


MINOR: Set default group.consumer.migration.policy to BIDIRECTIONAL

This is a small pr to change the default value of group.consumer.migration.policy to BIDIRECTIONAL.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@dongnuo123, could you please merge the trunk to include the build fix?

Reopened the PR in https://github.com/apache/kafka/pull/17295


Fix repetition error

<unique-frontend-app-name> was repeated. Should be <unique-frontend-app-name> and <unique-backend-app-name>

#sign-off


Fix behaviour of determining dhcp primary/secondary

When there is more than one CARP address per interface, with different
advskews which is typical in active/active configuration we need to
check only the first CARP if and skew in order to determine primary.
Previously if you had two CARP vips where VIP a had skew <20 on host A
and VIP b had skew <20 on host B, both hosts would be configured as
primary, and dhcp failover would not be configured correctly.
The caveat to this fix is that VIPs need to be configured in the same
order on both hosts.

[ ] Redmine Issue: https://redmine.pfsense.org/issues/NNNN
[ ] Ready for review

Maybe this behaviour should be further clarified also in the descriptive text "Failover peer IP", to ensure that VIPs are configured correnctly for people who run such a setup?

Active/active is not a supported configuration, all skews on the master should be identical.

Active/active is not a supported configuration, all skews on the master should be identical.

Sure, but then the patch could simply be reworded as "All skews should be identical, no need to check more than one.", if that helps. No mention of active/active, and slightly more efficient code :)
Currently serving 20k clients from these boxes, we need to load-balance clients which we accomplish using separate dhcp pools with different default routes (CARP VIPs). We've been applying this patch for two years, so its reasonably battle tested. That's the motivation, just would rather not have to apply the patch every update.


fix(roi_cluster_fusion): add unknown-object removal

Signed-off-by: badai-nguyen<EMAIL_ADDRESS>Description
This PR removes the Unknown objects remained after camera rois and clusters fusion. The purpose is to reduce detected obstacles coming from pointclouds such as exhaust gas or dense raindrops.
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@yukkysaito

I want to remove UNKNOWN objects only for clustering and roi fusion. If the result with CenterPoint does not match, will it still be output?

yes, this only remove UNKNOWN right after fusing clustering and roi, so not-matched results with CenterPoint will be remained.


Send and TC Enhancement: New signature for the update trusted contact action

Support the new signature for the UPDATE_TRUSTED_CONTACTS_INFO action
https://github.com/bithyve/hexa/compare/feature/send-flow-refactoring#diff-234c270f5e617d5465e01e5cb081d9fa6d037ce5b152c2cf474beec6908390b6R218
FYI @CypherPoet

Will require more details.

This is done. Trusted contacts getting added is a test for this which has been done.


[SPARK-41977][SPARK-41978][CONNECT] SparkSession.range to take float as arguments

What changes were proposed in this pull request?
This PR proposes to Spark Connect's SparkSession.range to accept floats. e.g., spark.range(10e10).
Why are the changes needed?
For feature parity.
Does this PR introduce any user-facing change?
No to end users since Spark Connect has not been released yet.
SparkSession.range allows floats.
How was this patch tested?
Unittests enabled back.

@dongjoon-hyun
good question. range in Connect has the same signature as the PySpark's one, which should only accept intergers.
But PySpark's implementation doesn't check the input type
https://github.com/apache/spark/blob/56c7cf33929d7d42b7d299c0bb7e895963241214/python/pyspark/sql/session.py#L788-L796
and in some cases / tests, the floats are used, like range(10e10).
We might need to update the typing for both Connect and PySpark in the future.

Yeah .. so technically it should only take ints as that's what the method wants. There are a lot of cases like that in PySpark (e.g., DataFrameReader.jdbc), and a lot of discussions happened.
The take is: type desired signature, and do not type the signature supported by casting (and keep it as a legacy behaviour).
Here I fixed Spark Connect's range to match with the legacy behaviour of the regular PySpark's range.


Fix tests for wagtail 2.11

Fixing the tests for wagtail 2.11 as mentioned in issue 158
There were two changes in wagtail 2.11 that broke the tests:

Consistently redirect to admin home on permission denied (Matt Westcott, Anton Zhyltsou)

When using wagtail 2.11, permission denied errors are redirected to the home page rather than returning a 403.

SiteMiddleware moved to wagtail.contrib.legacy

We need to remove wagtail.core.middleware.SiteMiddleware from the settings.py file unless the tests are running in an older version of wagtail, in which case we still need it as version 2.8 of wagtail uses it here
I've not used tox before, so I'm unsure if there's a cleverer way to go about these dynamic tests. Let me know if I can improve it in any way

if you want to make it right and support future updates as well you should think about changing code regarding site and request since they are deprecated:
https://docs.wagtail.io/en/stable/releases/2.9.html
read this at SiteMiddleware and request.site deprecated

Unless I'm misunderstanding you, I think thats what I've done? wagtailstreamforms itself doesn't seem to actually use request.site, so no code changes are necessary.
But when the tests run with the different versions or django and wagtail, they potentially still need 'wagtail.core.middleware.SiteMiddleware' in the list of apps (for example if the tests run with version 2.8 of wagtail), hence removing it from the example app here and adding it in dynamically in the test app here

then everything should be fine. looking forward to the next release :)

@dbramwell The version check in the test settings looks fine to me, I doubt much can be improved there. Thank you for fixing this!

@dbramwell The version check in the test settings looks fine to me, I doubt much can be improved there. Thank you for fixing this!


Inline Query for Live Preview

Discussed in https://github.com/blacksmithgu/obsidian-dataview/discussions/728

Originally posted by DryIce1 December 16, 2021
Hi @blacksmithgu,
I wonder if you could implement Inline Queries for Live Preview as you have for normal dataview queries.
Why it is useful

learning from one's past reflections is a super powerful way to track progress

How I am using inline queries

I use Inlines heavily for journalling and reviews
each journal links to the previous journal note and the next date level up

the daily note links to yesterday and this week
the weekly review links to last week and this month.
the monthly reviews link to last month and this year.

e.g then from today's daily note I can get fields from all the weekly/monthly/yearly review notes that relate to this page

=this.yesterday.highlights
=this.week.last-week.to-improve
=this.week.month.theme
=this.week.month.last-month.theme
=this.week.month.year.highlights

At each larger time period I am summarising and learning from my reflections.
in the weekly review, =this.days.gratitude - to summarise what I was grateful for this week
in the monthly review, =this.weeks.gratitude - to summarise what I was grateful for this month
in the yearly review, =this.months.gratitude

I have put my current daily / weekly / monthly review templates over here if anyone wants to use them, feel free to contact me to make any suggestions, critiques or feedback.
Current Problem

not being able to see these reflections in the inline query whilst editing in Live Preview.

on the desktop having to have two panes open (edit and read mode)
on mobile, it's really not possible to do these kind of reflections in edit mode

Solution

inline queries rendered in Live Preview.

I am interested in knowing if

other people are doing this, or what other techniques people are using
If this feature is currently on the Dataview development roadmap

Thanks for considering,
Tom

Agreed, it will be very helpful!

I think this needs to be implemented as a CodeMirror plugin and not as an Obsidian post processor; I don't know how to do this yet so I'll have to figure it out. The good news is it will look cool when it works!

Would be very useful to me! Hope one day would be possible to render inline query’s in live preview

I wonder if I could politely bump this issue of Inline Expressions for Live Preview. Switching to Read Mode in order to see the data is high friction, and dramatically interferes with how incredible powerful Inline Expressions can be for learning and reflection.

The good news is it will look cool when it works! - @blacksmithgu

I agree! Here are some examples of Inline Expressions in LP and Reading Modes using my daily/weekly templates. I use primary theme, banners plugin, embedded headers plugin, and a couple of short snippets (that I have posted here).
Daily Notes

Live preview:

Read mode with inline expressions rendered

Weekly Notes

live preview - where it is useful to me, I would write a summary for each category using the prompts from the daily data generated by the inline expressions.

Reading Mode - an example of how things roll up from daily notes (incomplete this week!)

thanks for your work @blacksmithgu
best

In case folks don't know, I was extremely pleasantly surprised to discover that inline queries and inline JS expressions work in live preview when placed inside a call out - both the title and the body!
While it would still be great to see inline expressions work everywhere in live preview, as someone exclusively uses live preview this is a huge improvement in my book!
In Edit Mode:

In Live Preview:

I posted in the plugin channels in discord, maybe someone with some CM experience could come and take a look :)

I think it could be implemented similarly to this: https://github.com/artisticat1/obsidian-latex-suite/blob/47152d63c3ada749fb957e9d913392e67f4eb76b/src/conceal.ts#L219
Instead of returning a symbol it would call the markdownPostProcessor on the markdown and return that element.

I tried implementing it, but couldn't figure out how to render inline fields.
Can someone point me to what I'd need to call and what to pass for them? (the code isn't pushed to my fork)

I tried implementing it, but couldn't figure out how to render (or rather parse) inline fields.
Can someone point me to what I'd need to call and what to pass for them? (the code isn't pushed to my fork)

Given a section of plaintext, you can obtain all inline fields and their offsets using extractInlineFields from https://github.com/blacksmithgu/obsidian-dataview/blob/master/src/data-import/inline-field.ts.

@kometenstaub If you want inline queries, then just search for code elements in the Markdown AST and verify they start with the inline query prefix (from settings.inlineQueryPrefix). You can reuse the existing render code for inline fields/queries to make the actual DOM element.

I'm not sure how the markdown AST in codemirror works so there may be some console.log exploration required...

Thank you @kometenstaub & @blacksmithgu  🎉This is awesome!!


Bump to Go 1.22 - Pin latest contrib with Go 1.22

Description
Pin the latest contrib which now uses Go 1.22, as a result use Go 1.22 in Runtime also.

/ok-to-test

FYI - E2E tests have actor related E2E failures, but this isn't related to any contrib changes. Probably should be investigated separately against master branch.

Unclear why this complains about gotestsum not being found and as a result fails the unit tests. It works perfectly locally on Apple Silicon.

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

Now tests should run again with CosmosDB 1.0+ (the way a NotFound response was returned changed when the SDK was made stable)

@JoshVanL @yaron2 @artursouza can you merge this?
@JoshVanL by the way it seems that switching the Go version to 1.22 impacts gotestsum on macos and other platforms (but not Linux). That's somehow runtime specific.

FYI Windows test is fine - it completed almost all tests but then timed out at the end.

Thanks @berndverst! I have opened https://github.com/berndverst/dapr/pull/63 to update the rest of the go.mods and updated an integration test fuzz generator to account for the new Go HTTP route key characters.

Thanks @berndverst! I have opened berndverst#63 to update the rest of the go.mods and updated an integration test fuzz generator to account for the new Go HTTP route key characters.

I merged your PR @JoshVanL

Feel free to push commits directly to my branch to fix things - as runtime maintainers you can do that. (I do it a lot for contrib contributions to fix up PRs)

Tests are still getting /bin/sh: gotestsum: command not found on Mac and Windows. No idea why. I cannot reproduce this locally.
Runtime maintainers, please push commits to fix directly to this PR. I am not looking at PRs opened against my branch.

Thanks @berndverst, I have pushed a commit which should resolve the MacOS test runner error.

@holopin-bot @berndverst Enjoy your Dapr badge!