Use PY38 and add handle function check

@pavelzubarev I was unable to find a working distroless container image running python 3.8.... so I added one that is probably "too large" for what is necessary? Do you have some input here?
The rest of the code is an AST check for handle function args, allowing us to run verification without actually installing & loading modules.

...and tested working for decorated handle-functions, just now


Auto-update working only once

Problem
Hello guys.
First of all, thank you very much for awesome plugin.
My problem is the auto-update is executed only once. (Kill the app completely and re-start the app)
I checked wiki and issues for days but no luck.
Please let me know what I am missing.
Here is my steps :

Develop and commit to the server
Server executes cordova-hcp build (I didn't execute cordova-hcp init)
So it will create new chcp.json and chcp.manifest
Check if chcp.json that is generated by server and release are correctly generated.
In the Xcode, open my project and launch iPhone simulator. ( iPhone5(9.1) )
First launch, I can see the update works as I committed to the server.
Ok. seems update is working, I do the same steps from 1 to 4
Wait until auto-update but, nothing happens.
Turn off iPhone simulator and re-launch it then update working.

config.xml
<chcp>
      <config-file url="myServer/chcp.json"/>
      <auto-download enabled="true" />
      <auto-install enabled="true" />
</chcp>

I do not use javascript at all because

By default, all update checking->downloading->installation cycle is performed automatically by the plugins native side.

System info
Run cordova info (or ionic info) and paste it here, or give us information like:

Platform: iOS
Platform version: 9.3.5
Cordova version: 6.0.0
Ionic version: 1.7.14
Node version: 5.6.0

Thank you.

Hi,
thanks :)
Yes, right now it pings for server update only when the app is launched, not just resumed. And it's not pinging for updates while it's active in order to save battery and user's traffic.
There's a plan to change that a bit: https://github.com/nordnet/cordova-hot-code-push/issues/161#issuecomment-230724698 .
But if you want to control when the update is performed - you need to use JS API. Luckily, it's not that complicated :) For example, you can just add chcp.fetchUpdate() method call on ready event and ignore the callback. Disable auto-downloads, but leave auto-installs active.

@nikDemyankov
Thank you very much for the answer.
I was sure I can make auto-update anytime because I have the experience while the local test that uses cordova-hcp server
(For example, if I change css and save and it updates a few seconds later on the iPhone simulator.)
I will try javascript way that you suggested me!
Thank you again!

Yeah, the local test with cordova-hcp server works like that with dev plugin because of the dev plugin :) It connects via socket to the local server and listens for file changes in it. When detected - it tells the main plugin to fetch the update. In production you don't want this behaviour, because it will drain user's battery.

@nikDemyankov
I could resolve the problem using 'resume' event.
$ionicPlatform.on("resume", function(event) {
    chcp.fetchUpdate(function(error, data){
    	//code here
    });
});

Because I want user's mobile to check if there is the update from the server whenever it comes back from background to foreground.
Thanks again!

Cool, closing it then :)


update version to test cluster-bot

Don't merge. This PR is only for debugging https://issues.redhat.com/browse/OCPCRT-217
/hold

Close it since https://issues.redhat.com/browse/OCPCRT-217 has been addressed.


Fix nil-dereference in controller

Fixes a nil-deref when the following conditions are all true:

gitSpec.Checkout is nil
origin.Spec.Reference is nil
gitSpec.push is nil

Signed-off-by: David Korczynski<EMAIL_ADDRESS>

Discussed this with @squaremo internally

This PR also fixes another issue which is it adds a return on the failWithError - this didn't occur in the specified place which cause the reconciler to continue execution after the call to failWithError


Add menu in snake game

Menu with some options. At least:

New game (or start game)
Exit
Change size?
Change speed?

Also use it to keep track of score.

Menu added. Speed and size buttons not yet implemented. But I can start new game, and exit the program.

Added a help button.

The speed button is now implemented, as described in issue #50.

The speed button is now implemented. Speed is defined as a factor, that can be one of the following: 0.5, 0.8, 1, 1.2, 1.5, 2. Game starts with factor=1, and each time the button is pressed in will change to the next value of the list.
The factor is used to divide the time between updates: so the higher the factor, the less time between updates, hence higher is the speed. The speed changes immediately when pressing the button.
Right now pressing the button displays a popup message, but not sure if I want to remove the popup... I'll leave it like this for now.

All buttons implemented, now the issue can be closed.


sql multi colunms and dynamic prameters combination translation mapping to an specific value

Version:4.13.1 or earlier
Now due to  the mechanism of  the sql translation mapping with sql data cache,we can only translate an specicic column to a value instead of Left join sql or writing java codes with same purpose,But there are some scenarios that the current mechanism can't work with.
For in some multi-language scenarios,or in the composite keys/composite columns ,several columns or several dynamic parameters or all the columns and parameters combiation can only mapping to an specific translation value,this orm-framework can't work with it well.
In my opnion,we can wite the sql template just like ,
Select (column1 column2 ....   :param1 :param2 ...) columnName instead of Select colunm1 columnName ,
which indicates that  the combination of multi colunm or java parameter with : is the final key which can be used to map to the final translation values as before.
That is my suggestion,you can follow this idea and add it to the orm-framework as you like,wharever.

计划下一版可以让开发者在代码层面加入缓存翻译，针对特殊场景由开发者来动态设置缓存翻译，为程序提供更多的灵活空间!

4.13.5 版本里面已经支持


AC0 filter in gnomAD v2 subsets

The filters field is based on the full gnomAD v2 dataset. Thus, when requesting a subset, variants may have an allele count of 0 but not the AC0 filter.

Resolved in 821a0a243f4c4fcc67489e3dc1af9dc6f1108e02.


PSE spawning habitat data flow

should PSE spawning data continue to be held in user_habitat_classification.csv or be stored elsewhere?
should we expect updates to confirmed spawning data from PSE?

No updates expected in the short term. Leave data where it is for now but plan to improve this in the futre.


add --fork-transaction-hash

Motivation

Feature requested by #8227
Solution

Add --fork-transaction-hash flag which conflicts with --fork-block-number
Convert Option used by the existing fork flow into a ForkChoice enum
Deduce the block number from the transaction hash to determine which hard fork to use

@HrikB I have made a draft pr here in any case. LMK if you would like me to continue on it

@mattsse could you please approve this workflow as it is my first PR to the repo 🙏

forcefully include them when the first block is triggered

ah, this could actually be done by adding another mining mode variant:
https://github.com/foundry-rs/foundry/blob/d7eac74cfd786447cec9650048e2d2fac63fba0c/crates/anvil/src/eth/miner.rs#L99-L108
that wraps the existing variant, but for the first time it is called it yields the txs:
https://github.com/foundry-rs/foundry/blob/d7eac74cfd786447cec9650048e2d2fac63fba0c/crates/anvil/src/eth/miner.rs#L124-L129


Error Payload data on publish images

Hi, I newer in pylon_camera node. I'm try to connect a Basler daA1280 USB3.0 in USB2.0. Pylon Viewer and ROS node run ok but when I run rqt_image_view to watch the image, the pylon node show this error message:
Pylon camera returned invalid image! Skipping
Error:<PHONE_NUMBER> Payload data has been discarded. Payload data can be discarded by the camera device if the available bandwidth is insufficient.
Error: Grab was not successful
If I run first rqt_image_view and then pylon_camera_node,  the error does not appear. Why?
Thanks in advanced

HI, I have the same problem. Did you find the solution @edmodi ?

HI, I have the same problem. Did you find the solution @edmodi ?

Not yet. I'm try but I can not solved it

Hi, I change DeviceLinkThroughputLimitMode parameter to Off and run ok
@GianlucaCerilli  could you confirm it?
Thanks

Hello!
@edmodi @GianlucaCerilli any news in this side?
(same problem, can't figure out how to change the param in the code)
cheers!

Hi @MamounGharbi,
Same problem for me..Maybe @edmodi can help us.
Cheers

I'm sure you have it figured out by now, but in case someone else comes looking, I had the same issue and I also resolved it by setting the DeviceLinkThroughputLimitMode to off.  I added the following to pylon_camera_usb.hpp under the PylonUSBCamera::applyCamSpecificStartupSettings function:
cam_->DeviceLinkThroughputLimitMode.SetValue(Basler_UsbCameraParams::DeviceLinkThroughputLimitMode_off);

I solved the problem by increasing the Maximum Transfer Size.
You find this parameter in pylon Viewer at Stream Parameters and with the ros camera driver with the rosservice: "rosservice call /pylon_camera_node/set_max_transfer_size 150000"


[BUG] the package! highlight disappear when disable magit module

Describe the issue
the package! highlight disappear when disable magit module
Steps to reproduce

disable magit module
open a packages.el

System information

emacs   version    26.2
        features   XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD LCMS2
        build      4月 13, 2019
        buildopts  (--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now)
doom    version    2.0.9
        build      HEAD -> develop, origin/develop abcc7d06 2019-09-04 16:07:52 +0800
system  type       gnu/linux
        config     x86_64-pc-linux-gnu
        shell      /usr/bin/zsh
        uname      Linux 4.19.66-1-MANJARO #1 SMP PREEMPT Fri Aug 9 18:01:53 UTC 2019 x86_64
        path       (/usr/local/bin /usr/bin /bin /usr/local/sbin /opt/android-ndk /usr/lib/jvm/default/bin /usr/bin/site_perl /usr/bin/vendor_perl /usr/bin/core_perl /usr/lib/emacs/26.2/x86_64-pc-linux-gnu)
config  envfile    nil
        elc-files  0
        modules    (:completion company ivy :ui doom doom-dashboard doom-quit hl-todo modeline nav-flash ophints (popup +all +defaults) workspaces prow-hydra :editor file-templates snippets :term term :tools gtags :lang emacs-lisp :email mu4e :config default)
        packages   (n/a)
        elpa-packages (n/a)

This isn't really a bug. It happens because magit loads itself after a short delay, after startup, which pulls in package.el, which causes Doom to initialize all its package management metadata (including the definition for package!, which causes it to be highlighted).
Without the :tools magit module, nothing causes this chain of events and Doom's package management system is never loaded (until you load the package.el or straight.el library).

@hlissner this sounds strange.

Emacs highlights macros that have been defined. Since core-package.el (where package! is defined) is lazy loaded, package! calls will not be highlighted until it is loaded.
If you disable the magit module and open ~/.doom.d/packages.el, you'll see package! is unhighlighted. Then do M-x load-library RET core-packages and you'll see it become highlighted. If you load package or straight, it will load core-packages because of these lines.
It would be easy to have it highlighted no matter what with this:
(font-lock-add-keywords
 'emacs-lisp-mode '(("\\_<package!\\_>" . font-lock-keyword-face)))

But I think it's more important to not hide the fact that a macro hasn't been loaded. Syntax highlighting is a good indicator that a macro hasn't been loaded in the current session.

@hlissner thanks for your reply:+1:


"Geographical Distribution" graph is very jumpy

Switching between the Stargazers / Issue Creators / PR Creators tabs completely moves around the dots on the map and they fly all over the place for the duration of the animation.
The dots on the map should rather have a stable identity by the country they are associated with, rather than their order in the list of countries. That should avoid movement of the dots, and rather just animate their size.

thanks for your reminder


query gives 401 www-authenticate API key is missing or invalid for the environment

I log the index to the console, and it appears to have been initialized. Then I make a query using:
    async function getPineconeContexts(index, vector) {
        const queryRequest: QueryRequest = {
            topK: 10,
            vector
        }
        const queryResponse = await index.query({ queryRequest });
        return queryResponse;
    }

And the call returns a 401 with the following response headers. (I think the CORS is a red herring, that typically results from 401). The key thing, I think, is www-authenticate API key is missing or invalid for the environment "us-west1-gcp". Check that the correct environment is specified. Does the queryRequest payload need to include the API key, somehow?
XHROPTIONShttps://pure-gas-8a31658.svc.us-west1-gcp.pinecone.io/query
CORS Missing Allow Origin

OPTIONS
	https://pure-gas-8a31658.svc.us-west1-gcp.pinecone.io/query
Status
401
Unauthorized
VersionHTTP/2
Transferred368 B (0 B size)
Referrer Policystrict-origin-when-cross-origin
    content-length
    	114
    date
    	Tue, 14 Mar 2023 23:32:11 GMT
    server
    	envoy
    www-authenticate
    	API key is missing or invalid for the environment "us-west1-gcp". Check that the correct environment is specified.
    X-Firefox-Spdy
    	h2

    Accept
    	*/*
    Accept-Encoding
    	gzip, deflate, br
    Accept-Language
    	en-US,en;q=0.5
    Access-Control-Request-Headers
    	api-key,content-type
    Access-Control-Request-Method
    	POST
    Cache-Control
    	no-cache
    Connection
    	keep-alive
    DNT
    	1
    Host
    	pure-gas-8a31658.svc.us-west1-gcp.pinecone.io
    Origin
    	http://localhost:3000
    Pragma
    	no-cache
    Referer
    	http://localhost:3000/
    Sec-Fetch-Dest
    	empty
    Sec-Fetch-Mode
    	cors
    Sec-Fetch-Site
    	cross-site
    User-Agent
    	Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0

Upon further review, I think an issue is that I cannot form a proper QueryRequest in my React environment.  So if that's the case, we can delete this issue. I'm more interested in seeing the tests run successfuly in a clean clone of this repo. :)

Ahhh, there is no payload for the request. The QueryRequest isn't being sent to the server! That is bad. I'm not sure the api-key is at fault.

The code seems perfectly fine. Are you positive there's a vector that's being passed to the function? Other than that I can't really think of anything that would cause this failure.

Definitely there is a payload, I'm creating it manually. Can you point me to an example that actually works? I have literally not seen one since the tests all fail. Once I see an app that queries an index successfully I'll be all set.

@sammyjava is this still happening?

I am also facing the same issue. Looks like everything is fine to me. Not sure how to circumvent it?

I'm going to close this issue since there hasn't been recent activity. Today we published a v1.0.1 release with a ton of improvements. Please try the new release, see the v1 Migration Guide, and open a new issue if you're still having trouble.


Declare @babel/core as peer dependency

This avoids issues with yarn 2 complaining about package not providing @babel/core.
➤ YN0002: │ babel-plugin-jsx-dom-expressions@npm:0.33.8 doesn't provide @babel/core (p9ac8d), requested by @babel/plugin-syntax-jsx

See https://dev.to/arcanis/implicit-transitive-peer-dependencies-ed0 for more details.

Thanks


Always return the Event object, regardless of what the async block returns.

When using an async block, the capture methods would return the block returned value when called or the Event object when async isn't defined, which could possibly break any client code that would always expect the event object instead of a ActiveJob::Base instance or a Sidekiq job, for instance.

:+1: for always returning the same type!


voidtools.Everything.Lite updated to latest version but winget keeps showing update available

Brief description of your issue
Winget shows that an update is available, even though the software is up to date with the latest version. (id="voidtools.Everything.Lite" version="<IP_ADDRESS>2")
winget upgrade
Name                             Id                        Version      Available  Source
-----------------------------------------------------------------------------------------
Everything <IP_ADDRESS>2 Lite (x64) voidtools.Everything.Lite < <IP_ADDRESS>5 <IP_ADDRESS>2 winget
1 upgrade available.

Steps to reproduce
winget install "voidtools.Everything.Lite"
winget upgrade
Expected behavior
No available updates should be displayed (with "winget upgrade") if the latest version is already installed.
Actual behavior
Winget shows that an update is available, even though the software is up to date with the latest version.
Environment
Administrador de paquetes de Windows v1.3.2691
Copyright (c) Microsoft Corporation. Todos los derechos reservados.

Windows: Windows.Desktop v10.0.22621.819
Arquitectura del sistema: X64
Paquete: Microsoft.DesktopAppInstaller v1.18.2691.0

Registros: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

@jmaraujouy - Can you provide the output of winget list Everything ?

Yes, sure. ;)
winget list Everything
Nombre                           Id                        Versión      Disponible Origen
-----------------------------------------------------------------------------------------
Everything <IP_ADDRESS>2 Lite (x64) voidtools.Everything.Lite < <IP_ADDRESS>5 <IP_ADDRESS>2 winget

I just noticed that the manifest for v<IP_ADDRESS>2 shows "DisplayName: Everything <IP_ADDRESS>1" six times.
It should be <IP_ADDRESS>2.

Hello, @Dragon1573
Can you please fix the version number? (See my previous message)
I have no idea on how to make a pull request.

Can you guys please fix the version number? (See my previous message)

Em ...
I'm not sure if I can achieve it and fix this issue, but I think it worth a try.

@jmaraujouy ARP entries of voidtools.Everything is successfully fixed. But our problem here is about voidtools.Everything.Lite. I think you have searched a wrong place 😕
In the installer.yaml of voidtools.Everything.Lite with version <IP_ADDRESS>2, all ARP entries information seems correct. There's no "version number" issue as your comments above.
There should be something else causing the problem. No idea how to fix it ...

This problem is still there.  I tried creating a new (as simple as I could make it) manifest and testing with that.  winget still didn't see the installed version.
I think there is some problem with the way winget is identifying the installed version.  Looking at the registry, version information is there.
Should a problem be raised against winget-cli?

This problem is still there. I tried creating a new (as simple as I could make it) manifest and testing with that. winget still didn't see the installed version.
I think there is some problem with the way winget is identifying the installed version. Looking at the registry, version information is there.
Should a problem be raised against winget-cli?

What happens if you run winget list Everything

λ winget list everything
Name                             Id                        Version      Available  Source
-----------------------------------------------------------------------------------------
Everything <IP_ADDRESS>2 Lite (x64) voidtools.Everything.Lite < <IP_ADDRESS>5 <IP_ADDRESS>2 winget

I don't know if winget still looks for DisplayVersion in the registry.  The MSI installer for Everything Lite sets:
"DisplayVersion"="<IP_ADDRESS>2" in [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{2910A105-C9DA-45B0-97A5-F149D4773C23}].
It also sets up
"VersionMajor"=dword:00000001
"VersionMinor"=dword:00000004
"Version"=dword:01040001

settings/Apps & Features displays the version number correctly.
The exe installer sets up:
"DisplayVersion"="<IP_ADDRESS>2" but in key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Everything]
Again settings/Apps & Features displays the version number correctly.  However the version of Everything Lite as set up by this installer is again not recognised by winget.
Is there some confusion arising from the use of Everything and Everything Lite i.e. is winget looking for and not finding keys associated with Everything Lite rather than Everything?
(As an aside a similar problem arises with the Windows SDK, where after Visual Studio updates the SDK winget starts reporting an incorrect need to update - if we ever sort out Everything I'll check back on that.)

The issue here is related to https://github.com/microsoft/winget-pkgs/issues/91888#issuecomment-1380817845.
The versions <= <IP_ADDRESS>7 had inconsistent versioning scheme for the MSI Installers that forced us to use DisplayVersion in these manifests. https://github.com/microsoft/winget-pkgs/blob/d2baaa3a64bc8c164403ab25e128917e75019701/manifests/v/voidtools/Everything/Lite/<IP_ADDRESS>7/voidtools.Everything.Lite.installer.yaml#L24-L25
This got fixed by the publisher in subsequent versions where PackageVersion == DisplayVersion, so this field was no longer required. As stated in https://github.com/microsoft/winget-pkgs/issues/91888#issuecomment-1380817845, there are strange behaviors if some manifests contain DisplayVersion and others don't.
Per my understanding, the potential solutions are:

Remove versions prior than <IP_ADDRESS>0 that use DisplayVersion because of inconsistent versioning by the publisher.

OR

While the engineers advise against using DisplayVersion when it's equal to PackageVersion, adding DisplayVersion to all manifests may resolve the issue.

cc @denelon Could you please confirm this with an engineer?

Yes,
In general, the advice is:

If we need to have separate "packageVersion" and "displayVersion" values for one version of a package, then all manifests for that package should have "displayVersion".

If we do not need separate "packageVersion" and "displayVersion" values for any version of a package, then all manifests for that package should not have "displayVersion".

Have I got this right.

This is a fault with the manifest and should have been picked up when testing the manifest.
When I create a manifest which looks good and validates fine, it may not give the right behaviour because of the way previous manifests, which I have not looked at, have been set up. I may need to visit previous manifests when creating my new manifest.
The winget program cannot/will not be changed to allow a correct manifest associated with a correct installer to work correctly if a previous manifest had to be tweaked to cater for a deficient installer.

Sorry - I should have added thank you for fixing this @mdanish-kh

3. The winget program cannot/will not be changed to allow a correct manifest associated with a correct installer to work correctly if a previous manifest had to be tweaked to cater for a deficient installer.

I would say this isn’t entirely correct. There has been an issue filed over at winget-cli around this bug - https://github.com/microsoft/winget-cli/issues/2503.

This is a fault with the manifest and should have been picked up when testing the manifest.

Yes, kind of, but mostly no. The automated manifest tests don’t include an upgrade scenario, but there are requests open for this. The manifest was entirely correct, and actually installs fine, it just results in that upgrade loop. The tricky part is that in order to know if it will result in an upgrade loop, it has to be added into the source to see how the search results will come back, which requires it to be merged and published. Its a bit of a circular logic problem.

2. When I create a manifest which looks good and validates fine, it may not give the right behaviour because of the way previous manifests, which I have not looked at, have been set up.

Yes, this is true. However, this usually only effects a few packages. Using tools such as wingetcreate or YamlCreate also helps reduce the likelihood of this happening will generally prevent incorrect behaviors, but it isn’t a guarantee since someone else may submit a manifest that results in an incorrect behavior that gets propogated forward.

I may need to visit previous manifests when creating my new manifest.

Its not a bad idea to do this, but it isn’t required to do so. Because these behavior issues only occur in very specific conditions, once they are fixed they generally remain fixed, even as new versions are added. Even if they do occur, filing an issue here can result in it being resolved quickly. I did open https://github.com/microsoft/winget-pkgs/issues/92688 a little while ago which does suggest that the automated pipelines check for differences between the latest and previous manifest, but I'm sure that will take some time to be implemented (if ever)

Sorry - I should have added thank you for fixing this @mdanish-kh

The issue still persists - The only thing stopping me from creating PRs to add DisplayVersion to every manifest is I am unsure to how winget will sort these versions. I may end up creating another issue where users get an older version as the "latest" one if winget thinks 1.4.1017 > <IP_ADDRESS>2. I believe winget's implementation mimics semver as much as it can and online tools for version string comparisons as per semver show that 1.4.1017 is > <IP_ADDRESS>2. I may have to resort to solution#1 for removing older manifests with inconsistent versioning

The issue still persists
Ah I was being a little premature.  I should have been more cautious and said the issue is fixed for me on one machine at the moment....

@mdanish-kh WinGet will evaluate the version in the "displayVersion" key.
Yes, the following expression is true for WinGet version comparison:
1.4.1017 > <IP_ADDRESS>2
Removing versions that cause WinGet's evaluation logic to produce undesirable results is likely the best action to take for users.

Yes - I get exactly the same as you now.  Thank you again.

Close with reason: Resolved by removing old manifests causing version range issues;

Resolved in above PRs. @jmaraujouy @Dragon1573 @ajkajk Please check your output of winget list everything
~ winget list everything
Name                             Id                        Version    Source
-----------------------------------------------------------------------------
Everything <IP_ADDRESS>2 Lite (x64) voidtools.Everything.Lite <IP_ADDRESS>2 winget

Yes, its solved now. A big thank you to all involved in fixing this issue.


[Design] Can LROs be called as sync/async methods?

Will need to discuss with architects, possibly at arch board meeting.

We will address this with extension methods, as discussed here: https://github.com/Azure/azure-sdk-for-net-pr/pull/981/files#r398949391
@KrzysztofCwalina let me know if this is insufficient.


Fixes documentation for timeout

[X] I have read and agreed to the RethinkDB Contributor License Agreement http://rethinkdb.com/community/cla/

Description
Fixes #1190:

From rethinkdb/rethinkdb#6211:

On https://rethinkdb.com/api/java/#connect, it says that r.connection().timeout() is the timeout in seconds. It should say milliseconds.

Thanks.


addUserSignedOut called after signing in but not called after signout in another tab?

I have a react app in which I call signoutRedirect().  I also implemented the  addUserSignedOut event expecting that any other tabs open would respond to the user signing out and redirect accordingly. However the event is never fired after logout but is fired immediately after logging in?
What I am trying to achieve is that the user is logged out in all tabs.

Did you find a solution to this issue? I am also having troubles getting the event to fire after logout. However, i dont see it after logging in.


Refactoring for RPC "Feature"

Requires testing. What would a test look like for this? Manually setting the config to enable RPC, running the node, and running RPC commands? I see there are already RPC tests of some kind, but they seem to be more like unit tests rather than the "Is RPC running" kind of tests that this seems to require.

Generally if all the integration tests are passing RPC is tested.
The integration tests depend on RPC working correctly.


Fix the PR-Close action

currently the action is fireing on all PR close events.  It should only fire when folders that contain the listener are modified

PR: https://github.com/bcgov/nr-rfc-grib-copy/pull/90


Short solution needed: "Disable SSL check" (curl)

Please help us write most modern and shortest code solution for this issue:
Disable SSL check (technology: curl)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments to make solution explained.
Link to this issue in comments of pull request.

Disable SSL check


[Concurrency] don't require Sendable (yet)

We should not be enforcing Sendable usage (yet), so we need to remove the requirements from task group type parameters
This removes the requirement from:

task groups
task locals

@swift-ci please smoke test and merge

@swift-ci please smoke test and merge

Seems like the unit tests for task_local.swift:27 still have the requirement on them.

I presume there will likely be some magic later on to add requirements for these later when it is ready?

Yeah, Doug claims he has a plan for that, I don't know the details though/

@swift-ci please smoke test and merge


EPERM Exception when datastore is at the root of a disk on Windows

Hi,
I'm using NeDB in a custom NodeJS application that I maintain since 2018 and I'm still enjoying it.
I'm trying now to move to this fork.
In my use case the filename is in an external disk (USB or SD) and the target OS is Windows.
In the @seald-io/nedb implementation the load of the datastore throws an exception. Here a sample:
$ pwd
/c/Users/user/Desktop/tmp/seald

$ cat index.js
const Datastore = require("@seald-io/nedb");

try {
    // E:/ exists and I have RW permission
    const db = new Datastore({ filename: 'E:/tmp.datastore', autoload: true});
}
catch (err) {
    console.err(err);
}

$ node index.js

node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: EPERM: operation not permitted, mkdir 'E:\'] {
  errno: -4048,
  code: 'EPERM',
  syscall: 'mkdir',
  path: 'E:\\'
}

I tried different version of the library and this is what I got:
Versions <= 2.x -> it works
Versions >= 3.x -> it throws EPERM exception
Node: 18.18.2
OS: windows
Is this a regression?
Thanks!
Umberto

I admit this is not something I tested specifically, it might very well be a regression, the storage module has been rewritten completely with the promise based API of Node.js, there might be a difference between the two.
As I don't have a Windows environment at my disposal, could you change your code to a manual call to loadDatabaseAsync instead of relying on the autoload: true, and give me the stack trace please?

After a quick look, there might be something breaking: we introduced in 3.0.0 file / dir modes management, which should not be used on Windows as per Node.js documentation, but may very well be.
The modes NeDB now uses are 0o644 for files and 0o755 for directories, but Node's default is 0o666 and 0o777.
Could you set modes: { fileMode: 0o666, dirMode: 0o777 } in the options to see if it works?

Ok I think I got it:
basically, what seems to fails is the ensureDirectoryExistsAsync which executes fs.promises.mkdir('E:\', { recursive: true, mode: 0o755 }).
previously (before 3.0.0) it was fs.mkdir('E:\', { recursive: true }, callback)
The two differences are:

the mode was not settable before, we had to implement it, but I checked in libuv which is used by Node.js to perform the mkdir call, the argument is just ignored, it cannot be the mode.
the error management

Previously, the error were just ignored, see the implementation in v2.2.2 https://github.com/seald/nedb/blob/cd57534c906ca6c267f6c9f0d8282f58b4eb9ade/lib/persistence.js#L251
But in the reimplementation introduced in 3.0.0, I now catch the errors : https://github.com/seald/nedb/blob/07d0802b1df2d3db20fb201d799957f7714edeb9/lib/persistence.js#L303
I strongly believe it worked previously because of a mismanagement of the errors.
I think the same error would happen if we were to mkdir / on non-windows environements.
Another test which might be useful to debug this out, could you instantiate the Datastore in a subdirectory of E:\ like, E:\subDir\tmp.database.

Wow, with a subdir it works! no need to change modes :)
const db = new Datastore({ filename: 'E:/subDir/tmp.datastore' });

(async _ => {
	await db.loadDatabaseAsync();
})();

Do you think is it possible to support datastores in the root of the disks (like E:\datastore.db)?

Ok great, I think it is really the fact that you are at the root of the drive on Windows, and an mkdirp on it fails contrary to other OSes (I tested on Fedora, it works, on macOS it fails but with SIP even as root I cannot write to /test).
Basically, if in ensureDirectoryExistsAsync I check that the directory I want to mkdirp on is the root directory and just test a stat on it in this case instead of mkdirp, I believe it is feasible, however without a test bench it is hard to make sure, other things may break.
I'll try to release a preversion after testing with a colleague who has a windows env.

Good :D
Thanks for the support.
If you need further tests, let me know :)

@Type8 Can you please check that v4.0.3-0 works?

Hi :)
Actually i think something strange is happening. Here a quick example:
const Datastore = require("@seald-io/nedb");

const rootDatastore = new Datastore({ filename: 'E:/tmp.datastore' });
const subDirDatastore = new Datastore({ filename: 'E:/subdir/tmp.datastore' });

(async _ => {

	await rootDatastore.loadDatabaseAsync();
	await subDirDatastore.loadDatabaseAsync();

})();

The output is:
$ node  index.js
node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: ENOENT: no such file or directory, open 'E:\subdir\tmp.datastore'] {
  errno: -4058,
  code: 'ENOENT',
  syscall: 'open',
  path: 'E:\\subdir\\tmp.datastore'
}

@seald-io/nedb version:
  "dependencies": {
    "@seald-io/nedb": "^4.0.3-0"
  }

The line that throws is the
	await subDirDatastore.loadDatabaseAsync();

Ok, that's not right, thanks. I'll have to get hold of a windows env to make deeper tests.

Fun fact:
this example works!
const Datastore = require("@seald-io/nedb");

const rootDatastore = new Datastore({ filename: 'E:/tmp.datastore' });
const subDirDatastore = new Datastore({ filename: 'E:/subdir/anothersubdir/tmp.datastore' });

(async _ => {

	await rootDatastore.loadDatabaseAsync();
	await subDirDatastore.loadDatabaseAsync();

})();

I suppose the error is in how path.parse splits the path into { root, dir, base, ext,  name } .
IF the datastore path has only one subDir, the method ensureDirectoryExistsAsync is called twice:

first call has E:/ as a parameter and the result of path.parse is:

{ root: 'E:\\', dir: 'E:\\', base: '', ext: '', name: '' }

second call has E:/subdir as a parameter and the result of path.parse is:

{ root: 'E:\\', dir: 'E:\\', base: 'subdir', ext: '', name: 'subdir' }

so the mkdirAsync is never called.
When there is more than one subdir, the ensureDirectoryExistsAsync is called twice but the path.parse acts slighly differenty:

first call has E:/ as a parameter
second call has E:/subdir/anothersubdir as a parameter the result of path.parse is:

{
  root: 'E:\\',
  dir: 'E:\\subdir',
  base: 'anothersubdir',
  ext: '',
  name: 'anothersubdir'
}

With this object, the mkdirAsync is called correctly :)

Sorry, the ensureDirectoryExistsAsync run twice in my example because i am running the above example, where i'm working with 2 datatores.
Anyway i still think the problem is that path.parse does not react as we expect...
dir: E:/subdir/anothersubdir  ===> parsedDir:  {
  root: 'E:\\',
  dir: 'E:\\subdir',
  base: 'anothersubdir',
  ext: '',
  name: 'anothersubdir'
}
dir: E:/subdir ===> parsedDir:  {
  root: 'E:\\',
  dir: 'E:\\',
  base: 'subdir',
  ext: '', name: 'subdir' }

I think I had not understood correctly the documentation for path.parse:
┌─────────────────────┬────────────┐
│          dir        │    base    │
├──────┬              ├──────┬─────┤
│ root │              │ name │ ext │
"  /    home/user/dir / file  .txt "
└──────┴──────────────┴──────┴─────┘
(All spaces in the "" line should be ignored. They are purely for formatting.)

If I'm right, if the two following conditions are true, it means the tested directory is the root:

parsedDir.dir === parsedDir.root <- in the prerelease you tested, only this was tested
parsedDir.base === '' <- this should also be tested

Therefore, if one of the two is false, I execute the mkdir.
Let me retry.

Can you retry with v4.0.3-1 please @Type8.

It works for me :)
Thanks...

Released in 4.0.3, thanks!


Store listeners proposal

Griddle major version
1.8.0
Changes proposed in this pull request
Adding the ability to have listeners on the store independent of the "visual" part of Griddle. I am envisioning these to be used for running callbacks from the outside world, for example those provided on the "events" object.
Why these changes are made
Instead of having an event callback passed down to the component that would trigger it, for example on the pagination buttons, a listener function can subscribe to the store and trigger the "onNext" event when the pagination state has changed in the store. This would make for a better separation of concerns between how the state is changed and what has changed.
I am running into use cases where I want to be listening on the change of a particular plugin's store subset to run an externally provided call-back but would have to hook into UI events in several places to make this work. It would be great if there was just a single place to keep this sort of behaviour.
And of course it's not required to make all events use this design, this is just supplementary.
This is also not a ready-to-merge PR, I have a question: right now I am only getting listeners from plugins, do we want to allow listeners to be passed in as props on  as well? And in that case, will have to update typescript stuff too.
Are there tests?
No

I bumped into something last night where this functionality would be really useful. I like this -- I personally would prefer being able to add them as props as well (and would require typescript updates for the .d.ts stuff)
It would be really cool if you had the time to make a story in storybook for wiring this up.

Yeah, I'll add them to the props as well.
I was also thinking it would be handy to pass down the list of unsubscribe functions returned by store.subscribe on the context so that one could dynamically unsubscribe their listeners if needed. And move the subscribe function out into the utils so that they can be added as well.
Since the unsubscribes functions would need to be referenced somehow, for example in an object, this could cause name collisions if more than one listener was given the same name. I don't know if thats worth solving for right now?

Added a listeners prop to Griddle which takes an object of listener functions.
There is now a storeListener on the context which can be used to add and remove listeners dynamically in the components
Added typescript stuff, a review of this would be great
Added a storybook example, do we want more than one?

Thanks a ton for adding this! Will take a look - I think one storybook example is good 😄
I'll take a look at the TypeScript stuff but I've only been lightly using it for a couple months so if others want to weigh in too that'd be awesome.

I'm going to test on a couple more projects tomorrow and merge if all is good :+1:

👍  This is an awesome feature

This is in<EMAIL_ADDRESS>- which I've tested on a handful of my larger projects (and storybook) and all seems good. Thanks again
1.9.0 is now latest on npm


Make vercel a local dependency

https://github.com/chris48s/unfurl-preview/commit/437243acbaaf5e4a59000f370b1537969615708d

done in bebd27a4


[$4000] Typing emojis continuously in multi-line within the same single message doesn’t show in notifications on android

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

Action Performed:

Open mweb chrome from User A account
Go to chat section with User B
Type in multi lines (6-7 lines) of emoji within a single message and send it to User B (Make sure to login with user B on android)
Notice that multilines of emojis sent from user A doesn’t show on notification on user B android

Expected Result:
Sending multi lines of emoji within a single message should be shown in the notification section like texts
Actual Result:
Sending multi lines of emoji within a single message is not shown on the notification
Workaround:
unknown
Platforms:

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

[ ] Android / native

Version Number: 1.2.63-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/215894212-df5af399-2f2d-441d-8e90-81f36dacf9c2.mp4
https://user-images.githubusercontent.com/43996225/215894266-ad88c031-7c77-4fc0-90c5-f869c3fcfaa7.mp4
Expensify/Expensify Issue URL:
Issue reported by: @priya-zha
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1675166101726659
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0145bce78b355295bd
Upwork Job ID:<PHONE_NUMBER>543308288
Last Price Increase: 2023-02-16

reviewing

This could be due to some size limit in notifications' data.

Expensify uses urbanairship lib to handle notifications
https://github.com/Expensify/App/blob/aea38c5589521101938dd988de67b0b8f5b23f54/src/libs/Notification/PushNotification/index.native.js#L59
It seems to truncate ordinary text to 112 ascii symbols like this:
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012..."
but can't truncate emoji's
if a line ends with other symobls - it will be displayed in notification
but if there's only emojis - you can recieve only 28 emojis in notification which is two lines of 18 symobls (may be device specific)
It seems to be the limits of urbanairship implementation as documented here:
https://support.airship.com/hc/en-us/articles/213491643-What-are-the-Maximum-Characters-for-Push-Notifications-

No proposals

No proposals

I think the problem is on the server side (airship push server).

Sorry I haven't looked into this but I'll prioritize it tomorrow

@dylanexpensify updated my proposal with the template. Maybe this makes more sense now :)

I think we should confirm if this is in fact an airship notification. I think it's possible that we're exceeding 37-44 maximum character limit when sending more than 45 emojis, each of which has a string length > 2 because they're unicode characters

Once we confirm that's the case by finding the limit for an android device, and confirming a message with 1 less character makes the notification work, then I think we can discuss whether it's worth truncating these messages ourselves, and how to do it

I wrote the previous comment assuming the column notification drawer SystemNotification was the right one, but is that the one to look at or Notification drawer DefaultNotification Big Text Style? Lock Screen Portrait has the same values as notification drawer SystemNotification

@cead22 oh, thanks for this addition, I just didn't realized that there are more than 2-byte emojis. I'll make additional tests and post the results.

I thought I remembered there being some with length = 4, but I was very surprised by the one that returns 11

I thought I remembered there being some with length = 4, but I was very surprised by the one that returns 11

And there could be more when you change the skin color.
Here's 15-bytes: ``👩🏿❤💋👨🏾.length (skin color - black)

Updates on tests
So, posting test updates with new information about emojis
I'm making this test on a physical android device running android 13. Maybe this works different on a different version of android or physical screen/device.
Tested on production web.

ASCII single-string
You can send any string and get a notification. But if you have more than 110-115 symbols they get truncated like so:
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345..."
Here's another bug - quote here is incosistent (have seen it on slack, I will search for the link)
Suprisingly certain amount of symbols in string that is truncated differs and I don't know why.
ASCII multi-string
Such messages are truncated also on 110-115 symbols counting added \n symbols.
If you send short string of text (1\n2\n3\n4\n5\n6\n7\n8\n9\n0\n1\n2) 12 lines of text displays. And truncation doesn't work on the number of lines, additional text is just cut out. Also, if you have exactly 13 lines - they are shown in notification
Maybe this should be an additional bug
unicode characters single-string
JS uses UTF-16 so all unicode characters length === 1. But you can send only 38 utf-16 symbols like 茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶茶. if the string is >38 symbols there's no notification (also seen a bug in slack)
If you add ascii symbols in the end of 38 unicode symbols - they are truncated on the 39th symbol like so ...茶茶茶a..."
If you add ascii symbols in between and you have 38 unicode it won't display (seems like can't truncate)
unicode characters multi-string
Same as ascii - but if you send more then 13 lines - they won't show in notification
emojis 2-symbol (ordinary)
they behave like unicode but notification display only max 28 symbols as I wrote before
emojis 8-symbol
only 5-symbols. And those with 5 symbols could come with big delay like 1 minute.
emojis 15-symbol
only 3 symbols: 👩🏿❤💋👨🏾👩🏿❤💋👨🏾👩🏿❤💋👨🏾. You can add ascii symbols, they will be truncated. Managed to get this emojis split on truncation like on screen:

So, I think these weird bugs are server-side and the limit is in bytes around 110 bytes for the message. Server use optimal encoding so ascii is 1 byte, unicode 2 bytes. If we save 👩❤👩 in a text file - it's 20 bytes. In hex this is: f0 9f 91 a9 e2 80 8d e2 9d a4 ef b8 8f e2 80 8d f0 9f 91. But JS thinks that  👩❤👩.length === 8.

Not overdue - what are next steps here @eVoloshchak ?

@alexxxwork, wow, thank you for the thorough investigation!

what are next steps here @eVoloshchak ?

@dylanexpensify, it seems like this is indeed a server-side limitation, external contributors can't work on this.
I can confirm this happening on a physical Android device too, as well as the issue @alexxxwork was talking about here:

if the string is >38 symbols there's no notification (also seen a bug in slack)

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

@eVoloshchak I've made a proposal in similar issue to truncate notification strings to Airship on our side here: https://github.com/Expensify/App/issues/14849
I this a valid solution to this issue or should we address it upstream to Airship service?

Thanks for the detailed testing, there's a couple of things I didn't quite understand, but I'm asking Airship about any limitations or functionality they may have for truncating messages. I'll keep this issue updated with what I get

Hi @carlos I asked internally and was told that we do not have any functionality to truncate messages. But also, it's not expected the device would not receive the notification. The team recommended enabling verbose logging to see if the SDK is receiving a push or not.  It would also help if you could provide some examples of messages that aren’t coming through. We may want to open a ticket with support to take a look into it.

I shared the test video in this issue with them, but can you see if you can enable verbose logging (if not already enabled for dev) and check if there are any logs about the push notification in question?

@cead22 shall we move this internal?

I think so, at least for now until we're sure whether this can be fixed externally

Current assignee @eVoloshchak is eligible for the Internal assigner, not assigning anyone new.

I shared the test video in this issue with them, but can you see if you can enable verbose logging (if not already enabled for dev) and check if there are any logs about the push notification in question?

Sorry for the delay. Would it help to post metro logs? There are just nothing on missing notifications for the cases I mentioned in my investigation https://github.com/Expensify/App/issues/14715#issuecomment-1414433837 (multi-lined unicode and emojis strings)

They asked if we could provide logs from the Airship SDK and linked to this documentation page https://docs.airship.com/platform/mobile/logging/?groupid=ios-swift. Is that something you can pull?

They asked if we could provide logs from the Airship SDK and linked to this documentation page https://docs.airship.com/platform/mobile/logging/?groupid=ios-swift. Is that something you can pull?

@cead22 shure. Logs attached. 2023-02-22 00:31:38.293 17245-17245 New Expensify.log

Screens for this dialogue

@cead22 @eVoloshchak @dylanexpensify this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

Thanks for the logs, I sent them to airship, and I'm still waiting on a response from them

They got back to me with the following -- which I think is wrong, but please check my logic (my reply is below)

@carlos It looks like the device is receiving the push and we are trying to post it, assuming its this push:
2023-02-22 01:06:52.288 17245-22160 New Expensify - UALib   com.expensify.chat                   I  Processing push: {fromExpensify=true, com.urbanairship.metadata=eyJ2ZXJzaW9uX2lkIjoxLCJ0aW1lIjoxNjc3MDEwMDExOTIzLCJwdXNoX2lkIjoiNDY2ZTgxMDAtYjIyMy0xMWVkLTk3NTUtMDI0MjY0ZWY3ZDE5IiwiY2FtcGFpZ25zIjp7ImNhdGVnb3JpZXMiOltdfX0=, com.urbanairship.push.APID=0bd51415-27ec-48c4-a8cc-7767b80281d7, payload={"title":"spam@vcc.vc","type":"reportComment","reportID":4148003058225040,"shouldScrollToLastUnread":true,"roomName":null,"onyxData":[{"onyxMethod":"merge","key":"report_4148003058225040","value":{"reportID":"4148003058225040","maxSequenceNumber":47,"lastActionCreated":"2023-02-21 20:06:48.754","lastVisibleActionCreated":"2023-02-21 20:06:48.754","lastReadTime":"2023-02-21 20:01:24.544","lastMessageText":"\u20660123456789012345678901234567890123456789012345678901234567890123456789012345678","lastActorEmail":"spam@vcc.vc"}},{"onyxMethod":"merge","key":"reportActions_4148003058225040","value":{"2105426769474541683":{"person":[{"type":"TEXT","style":"strong","text":"spam@vcc.vc"}],"actorEmail":"spam@vcc.vc","actorAccountID":13031568,"message":[{"type":"COMMENT","html":"\u206601234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789","text":"\u206601234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789","isEdited":false}],"originalMessage":{"html":"\u206601234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789"},"avatar":"https://d2k5nsl2zxldvw.cloudfront.net/images/avatars/avatar_4.png","created":"2023-02-21 20:06:48.754","timestamp":1677010008,"reportActionTimestamp":1677010008754,"automatic":false,"sequenceNumber":47,"actionName":"ADDCOMMENT","shouldShow":true,"clientID":"","reportActionID":"2105426769474541683","isAttachment":false}},"shouldNotify":true}]}, com.urbanairship.push.CANONICAL_PUSH_ID=466e8100-b223-11ed-9755-024264ef7d19, com.urbanairship.push.PUSH_ID=47f5bd40-b223-11ed-8d98-02421fc6a487, com.urbanairship.notification_channel=4148003058225040, com.urbanairship.push.ALERT=0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901..."<EMAIL_ADDRESS>That means its probably an issue with either this - https://github.com/Expensify/App/blob/main/android/app/src/main/java/com/expensify/chat/customairshipextender/CustomNotificationProvider.java  but it looks fine to me or an OS issue. Are you able to reproduce on other devices?

CustomNotificationProvider.java
package com.expensify.chat.customairshipextender;
import static androidx.core.app.NotificationCompat.CATEGORY_MESSAGE;
import static androidx.core.app.NotificationCompat.PRIORITY_MAX;
import android.app.NotificationChannel;
import android.app.NotificationChannelGroup;
import android.app.NotificationManager;

You might be able to see a helpful error message in the notification service if you remove the filter on the app

My Reply
I don't think that's the right push, I think it's this one (I noticed Notification dismissed in there), since this is the one with a ton of emojis, and the one with a ton of emojis is the one we're not seeing. I'll check about the devices, I know this is happening on android but I'm not sure which specific devices
459 2023-02-22 01:02:17.381 17245-17245 New Expensify - UALib   com.expensify.chat                   V  NotificationIntentProcessor - Processing intent: com.urbanairship.push.ACTION_NOTIFICATION_DISMISSED
460 2023-02-22 01:02:17.381 17245-17245 New Expensify - UALib   com.expensify.chat                   I  Notification dismissed: NotificationInfo{alert=:grinning::grinning::grinning::grinning:
461                                                                                :grinning::grinning::grinning::grinning:
462                                                                                :grinning::grinning::grinning::grinning:
463                                                                                :grinning::grinning::grinning::grinning:
464                                                                                :grinning::grinning::grinning::grinning:
465                                                                                :grinning::grinning::grinning::grinning:, notificationId=1007, notificationTag='null'}
466 2023-02-22 01:02:17.382 17245-20975 New Expensify - UALib   com.expensify.chat                   V  NotificationProxyReceiver - Finished processing notification intent with result true.

Looks like this in the file actually, but I think slack is changing the emojis to text

@cead22 they got wrong log line. This is a truncated push with numbers, and we are talking about 13 lines of emojis.
Also, I made a service request to them in another issue and it seems that they just mixing the problems.

@cead22 in this issue https://github.com/Expensify/App/issues/14849 we are dealing with similar but different problem - Airship truncates strings and adds additional ...'' in the end of the line. So @parasharrajat asked to make a service request to Airship and I made one https://support.airship.com/hc/en-us/requests/89947 where I have provided the same logs and details about https://github.com/Expensify/App/blob/main/android/app/src/main/java/com/expensify/chat/customairshipextender/CustomNotificationProvider.java . So it seems that they are trying to merge our requests to one issue, but these are different cases :)

@cead22 let me know if there are any next steps here I can action!

Hi, I'm Fábio from Callstack and I would like to take a look at this issue.

@alexxxwork thanks for your help so far. We're going to take this internal and work with Callstack and Airship to resolve this given that it has gone 4+ weeks, but we'll be compensating you for your help so far

@cead22 @eVoloshchak @dylanexpensify this issue is now 4 weeks old and preventing us from maintaining WAQ. This should now be your highest priority. Please post below what your plan is to get a PR in review ASAP. Thanks!

I'm connecting Callstack and Airship on slack to help push this forward

I'll be posting here the investigations I did and that were also posted on Airship Slack's channel.

So, I did some investigation focusing exclusively on native side to debug and understand why we are having this issues on Android.
I did four tests basically:

Send a short message
Send a long message
Send a short message with emojis only
Send a long message with emojis only

Test 1 - Send a short message
I sent this message to the account that I’m using in my Android emulator.
Test

As you can see in my screenshot, the notification was sent to my emulator and it’s correctly styled.
We implemented a custom provider in our app to handle the notifications, and at this line he’ll have the following payload:
{
  "title"<EMAIL_ADDRESS>  "type": "reportComment",
  "reportID":<PHONE_NUMBER>045455,
  "reportAction": {
    "person": [
      {
        "type": "TEXT",
        "style": "strong",
        "text"<EMAIL_ADDRESS>      }
    ],
    "actorEmail"<EMAIL_ADDRESS>    "actorAccountID": 14356954,
    "message": [
      {
        "type": "COMMENT",
        "html": "Test",
        "text": "Test",
        "isEdited": false
      }
    ],
    "originalMessage": {
      "html": "Test"
    },
    "avatar": "https://d2k5nsl2zxldvw.cloudfront.net/images/avatars/avatar_3.png",
    "created": "2023-02-28 13:45:24.733",
    "timestamp":<PHONE_NUMBER>,
    "reportActionTimestamp":<PHONE_NUMBER>733,
    "automatic": false,
    "sequenceNumber": 59,
    "actionName": "ADDCOMMENT",
    "shouldShow": true,
    "reportActionID": "6374191708963222803"
  },
  "shouldScrollToLastUnread": true,
  "roomName": null,
  "onyxData": [
    {
      "onyxMethod": "merge",
      "key": "report_4530354462045455",
      "value": {
        "reportID": "4530354462045455",
        "maxSequenceNumber": 59,
        "lastVisibleActionCreated": "2023-02-28 13:45:24.733",
        "lastReadTime": "2023-02-28 09:57:09.605",
        "lastMessageText": "Test",
        "lastActorEmail"<EMAIL_ADDRESS>      }
    },
    {
      "onyxMethod": "merge",
      "key": "reportActions_4530354462045455",
      "value": {
        "6374191708963222803": {
          "person": [
            {
              "type": "TEXT",
              "style": "strong",
              "text"<EMAIL_ADDRESS>            }
          ],
          "actorEmail"<EMAIL_ADDRESS>          "actorAccountID": 14356954,
          "message": [
            {
              "type": "COMMENT",
              "html": "Test",
              "text": "Test",
              "isEdited": false
            }
          ],
          "originalMessage": {
            "html": "Test"
          },
          "avatar": "https://d2k5nsl2zxldvw.cloudfront.net/images/avatars/avatar_3.png",
          "created": "2023-02-28 13:45:24.733",
          "timestamp":<PHONE_NUMBER>,
          "reportActionTimestamp":<PHONE_NUMBER>733,
          "automatic": false,
          "sequenceNumber": 59,
          "actionName": "ADDCOMMENT",
          "shouldShow": true,
          "reportActionID": "6374191708963222803",
          "isAttachment": false
        }
      },
      "shouldNotify": true
    }
  ]
}

We can also see in the device logs that the library is processing the notification:
New Expensify - UALib: Processing push: {fromExpensify=true, com.urbanairship.metadata=eyJ2ZXJzaW9uX2lkIjoxLCJ0aW1lIjoxNjc3NTkxOTMxMDY2LCJwdXNoX2lkIjoiMjc3NjNmZTAtYjc2ZS0xMWVkLTlmODAtMDI0MjhhNzllZDMxIiwiY2FtcGFpZ25zIjp7ImNhdGVnb3JpZXMiOltdfX0=, com.urbanairship.push.APID=29a18e78-47f7-4fff-b063-9f4fe54c9b4d, payload={"title":"fabio.henriques+1@callstack.com","type":"reportComment","reportID":4530354462045455,"reportAction":{"person":[{"type":"TEXT","style":"strong","text":"fabio.henriques+1@callstack.com"}],"actorEmail":"fabio.henriques+1@callstack.com","actorAccountID":14356954,"message":[{"type":"COMMENT","html":"Test","text":"Test","isEdited":false}],"originalMessage":{"html":"Test"},"avatar":"https:\/\/d2k5nsl2zxldvw.cloudfront.net\/images\/avatars\/avatar_3.png","created":"2023-02-28 13:45:24.733","timestamp":1677591924,"reportActionTimestamp":1677591924733,"automatic":false,"sequenceNumber":59,"actionName":"ADDCOMMENT","shouldShow":true,"reportActionID":"6374191708963222803"},"shouldScrollToLastUnread":true,"roomName":null,"onyxData":[{"onyxMethod":"merge","key":"report_4530354462045455","value":{"reportID":"4530354462045455","maxSequenceNumber":59,"lastVisibleActionCreated":"2023-02-28 13:45:24.733","lastReadTime":"2023-02-28 09:57:09.605","lastMessageText":"Test","lastActorEmail":"fabio.henriques+1@callstack.com"}},{"onyxMethod":"merge","key":"reportActions_4530354462045455","value":{"6374191708963222803":{"person":[{"type":"TEXT","style":"strong","text":"fabio.henriques+1@callstack.com"}],"actorEmail":"fabio.henriques+1@callstack.com","actorAccountID":14356954,"message":[{"type":"COMMENT","html":"Test","text":"Test","isEdited":false}],"originalMessage":{"html":"Test"},"avatar":"https:\/\/d2k5nsl2zxldvw.cloudfront.net\/images\/avatars\/avatar_3.png","created":"2023-02-28 13:45:24.733","timestamp":1677591924,"reportActionTimestamp":1677591924733,"automatic":false,"sequenceNumber":59,"actionName":"ADDCOMMENT","shouldShow":true,"reportActionID":"6374191708963222803","isAttachment":false}},"shouldNotify":true}]}, com.urbanairship.push.CANONICAL_PUSH_ID=27763fe0-b76e-11ed-9f80-02428a79ed31, com.urbanairship.push.PUSH_ID=2acc21a0-b76e-11ed-aef1-0242e83d77e5, com.urbanairship.notification_channel=4530354462045455, com.urbanairship.push.ALERT=Test<EMAIL_ADDRESS>
So far so good, the payload is fine, it will be passed to our applyMessageStyle() method here in order to process it adding the avatar image and add this “Chat with...” text to the title, among with other things.
And it’s done, the notification will be shown as we expect.

Test 2 - Send a long message
I sent this message to the account that I’m using in my Android emulator.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

In my screenshot, the notification sent to my device has the problem discussed in this issue: the text is truncated and with a " at the end, and also we can notice that the notification is not styled as the first one with the short message, it’s missing the avatar image and the title with “Chat with...” text.
Also, for some reason, the payload is very small this time, missing two important properties (reportAction and onyxData) that we’ll need in our custom provider later:
{
  "title"<EMAIL_ADDRESS>  "type": "reportComment",
  "reportID":<PHONE_NUMBER>045455,
  "shouldScrollToLastUnread": true,
  "roomName": null
}

Log:
New Expensify - UALib: Processing push: {fromExpensify=true, com.urbanairship.metadata=eyJ2ZXJzaW9uX2lkIjoxLCJ0aW1lIjoxNjc3NTkyMzcwMzY2LCJwdXNoX2lkIjoiMmVlOTA3NzAtYjc2Zi0xMWVkLWE1NTEtMDI0Mjc1MWZiZjQ5IiwiY2FtcGFpZ25zIjp7ImNhdGVnb3JpZXMiOltdfX0=, com.urbanairship.push.APID=29a18e78-47f7-4fff-b063-9f4fe54c9b4d, payload={"title":"fabio.henriques+1@callstack.com","type":"reportComment","reportID":4530354462045455,"shouldScrollToLastUnread":true,"roomName":null}, com.urbanairship.push.CANONICAL_PUSH_ID=2ee90770-b76f-11ed-a551-0242751fbf49, com.urbanairship.push.PUSH_ID=30a3fde0-b76f-11ed-858e-02423fc6104c, com.urbanairship.notification_channel=4530354462045455, com.urbanairship.push.ALERT=Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna..."<EMAIL_ADDRESS>
Also please notice that this com.urbanairship.push.ALERT property from the log has this value Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna...", precisely the truncated text with the quote that we have in the notification.
Because of that, a exception is thrown at this line and we end up not applying any custom stylings and leaving to the library to apply the default ones. Then, I presume the library will use the com.urbanairship.push.ALERT property as the body of the notification.
NotificationProvider: Failed to parse conversation. SendID=30a3fde0-b76f-11ed-858e-02423fc6104c
NotificationProvider: java.lang.NullPointerException: Attempt to invoke virtual method 'com.urbanairship.json.JsonMap com.urbanairship.json.JsonValue.getMap()' on a null object reference
NotificationProvider: 	at com.expensify.chat.customairshipextender.CustomNotificationProvider.applyMessageStyle(CustomNotificationProvider.java:166)
NotificationProvider: 	at com.expensify.chat.customairshipextender.CustomNotificationProvider.onExtendBuilder(CustomNotificationProvider.java:101)
NotificationProvider: 	at com.urbanairship.push.notifications.AirshipNotificationProvider.onCreateNotification(AirshipNotificationProvider.java:210)
NotificationProvider: 	at com.urbanairship.push.IncomingPushRunnable.postProcessPush(IncomingPushRunnable.java:196)
NotificationProvider: 	at com.urbanairship.push.IncomingPushRunnable.processPush(IncomingPushRunnable.java:144)
NotificationProvider: 	at com.urbanairship.push.IncomingPushRunnable.run(IncomingPushRunnable.java:97)
NotificationProvider: 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:463)
NotificationProvider: 	at java.util.concurrent.FutureTask.run(FutureTask.java:264)
NotificationProvider: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
NotificationProvider: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
NotificationProvider: 	at com.urbanairship.util.AirshipThreadFactory$1.run(AirshipThreadFactory.java:50)
NotificationProvider: 	at java.lang.Thread.run(Thread.java:1012)

Test 3 - Send a short message with emojis only
I sent this message to the account that I’m using in my Android emulator.
🙂🙂🙂

Like the first test, the notification will be shown correctly with our custom stylings, so no problem here.
{
  "title"<EMAIL_ADDRESS>  "type": "reportComment",
  "reportID":<PHONE_NUMBER>045455,
  "reportAction": {
    "person": [
      {
        "type": "TEXT",
        "style": "strong",
        "text"<EMAIL_ADDRESS>      }
    ],
    "actorEmail"<EMAIL_ADDRESS>    "actorAccountID": 14356954,
    "message": [
      {
        "type": "COMMENT",
        "html": ":slightly_smiling_face::slightly_smiling_face::slightly_smiling_face:",
        "text": ":slightly_smiling_face::slightly_smiling_face::slightly_smiling_face:",
        "isEdited": false
      }
    ],
    "originalMessage": {
      "html": ":slightly_smiling_face::slightly_smiling_face::slightly_smiling_face:"
    },
    "avatar": "https://d2k5nsl2zxldvw.cloudfront.net/images/avatars/avatar_3.png",
    "created": "2023-02-28 14:03:17.657",
    "timestamp":<PHONE_NUMBER>,
    "reportActionTimestamp":<PHONE_NUMBER>657,
    "automatic": false,
    "sequenceNumber": 61,
    "actionName": "ADDCOMMENT",
    "shouldShow": true,
    "reportActionID": "6932692835455476580"
  },
  "shouldScrollToLastUnread": true,
  "roomName": null,
  "onyxData": [
    {
      "onyxMethod": "merge",
      "key": "report_4530354462045455",
      "value": {
        "reportID": "4530354462045455",
        "maxSequenceNumber": 61,
        "lastVisibleActionCreated": "2023-02-28 14:03:17.657",
        "lastReadTime": "2023-02-28 09:57:09.605",
        "lastMessageText": ":slightly_smiling_face::slightly_smiling_face::slightly_smiling_face:",
        "lastActorEmail"<EMAIL_ADDRESS>      }
    },
    {
      "onyxMethod": "merge",
      "key": "reportActions_4530354462045455",
      "value": {
        "6932692835455476580": {
          "person": [
            {
              "type": "TEXT",
              "style": "strong",
              "text"<EMAIL_ADDRESS>            }
          ],
          "actorEmail"<EMAIL_ADDRESS>          "actorAccountID": 14356954,
          "message": [
            {
              "type": "COMMENT",
              "html": ":slightly_smiling_face::slightly_smiling_face::slightly_smiling_face:",
              "text": ":slightly_smiling_face::slightly_smiling_face::slightly_smiling_face:",
              "isEdited": false
            }
          ],
          "originalMessage": {
            "html": ":slightly_smiling_face::slightly_smiling_face::slightly_smiling_face:"
          },
          "avatar": "https://d2k5nsl2zxldvw.cloudfront.net/images/avatars/avatar_3.png",
          "created": "2023-02-28 14:03:17.657",
          "timestamp":<PHONE_NUMBER>,
          "reportActionTimestamp":<PHONE_NUMBER>657,
          "automatic": false,
          "sequenceNumber": 61,
          "actionName": "ADDCOMMENT",
          "shouldShow": true,
          "reportActionID": "6932692835455476580",
          "isAttachment": false
        }
      },
      "shouldNotify": true
    }
  ]
}

New Expensify - UALib: Processing push: {fromExpensify=true, com.urbanairship.metadata=eyJ2ZXJzaW9uX2lkIjoxLCJ0aW1lIjoxNjc3NTkzMDA0NjgxLCJwdXNoX2lkIjoiYTZmNjY4NjAtYjc3MC0xMWVkLTgzZWQtMDI0MmU1Y2FkN2Q0IiwiY2FtcGFpZ25zIjp7ImNhdGVnb3JpZXMiOltdfX0=, com.urbanairship.push.APID=29a18e78-47f7-4fff-b063-9f4fe54c9b4d, payload={"title":"fabio.henriques+1@callstack.com","type":"reportComment","reportID":4530354462045455,"reportAction":{"person":[{"type":"TEXT","style":"strong","text":"fabio.henriques+1@callstack.com"}],"actorEmail":"fabio.henriques+1@callstack.com","actorAccountID":14356954,"message":[{"type":"COMMENT","html":"\ud83d\ude42\ud83d\ude42\ud83d\ude42","text":"\ud83d\ude42\ud83d\ude42\ud83d\ude42","isEdited":false}],"originalMessage":{"html":"\ud83d\ude42\ud83d\ude42\ud83d\ude42"},"avatar":"https:\/\/d2k5nsl2zxldvw.cloudfront.net\/images\/avatars\/avatar_3.png","created":"2023-02-28 14:03:17.657","timestamp":1677592997,"reportActionTimestamp":1677592997657,"automatic":false,"sequenceNumber":61,"actionName":"ADDCOMMENT","shouldShow":true,"reportActionID":"6932692835455476580"},"shouldScrollToLastUnread":true,"roomName":null,"onyxData":[{"onyxMethod":"merge","key":"report_4530354462045455","value":{"reportID":"4530354462045455","maxSequenceNumber":61,"lastVisibleActionCreated":"2023-02-28 14:03:17.657","lastReadTime":"2023-02-28 09:57:09.605","lastMessageText":"\ud83d\ude42\ud83d\ude42\ud83d\ude42","lastActorEmail":"fabio.henriques+1@callstack.com"}},{"onyxMethod":"merge","key":"reportActions_4530354462045455","value":{"6932692835455476580":{"person":[{"type":"TEXT","style":"strong","text":"fabio.henriques+1@callstack.com"}],"actorEmail":"fabio.henriques+1@callstack.com","actorAccountID":14356954,"message":[{"type":"COMMENT","html":"\ud83d\ude42\ud83d\ude42\ud83d\ude42","text":"\ud83d\ude42\ud83d\ude42\ud83d\ude42","isEdited":false}],"originalMessage":{"html":"\ud83d\ude42\ud83d\ude42\ud83d\ude42"},"avatar":"https:\/\/d2k5nsl2zxldvw.cloudfront.net\/images\/avatars\/avatar_3.png","created":"2023-02-28 14:03:17.657","timestamp":1677592997,"reportActionTimestamp":1677592997657,"automatic":false,"sequenceNumber":61,"actionName":"ADDCOMMENT","shouldShow":true,"reportActionID":"6932692835455476580","isAttachment":false}},"shouldNotify":true}]}, com.urbanairship.push.CANONICAL_PUSH_ID=a6f66860-b770-11ed-83ed-0242e5cad7d4, com.urbanairship.push.PUSH_ID=aab8c790-b770-11ed-86bc-0242915033f4, com.urbanairship.notification_channel=4530354462045455, com.urbanairship.push.ALERT=:slightly_smiling_face::slightly_smiling_face::slightly_smiling_face<EMAIL_ADDRESS>

Test 4 - Send a long message with emojis only
I sent this message to the account that I’m using in my Android emulator.
🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂🙂

This is the worst case, because in this test we didn’t receive any logs from Airship at all. It’s like it never hit the device. I can show in a video.
https://user-images.githubusercontent.com/20051562/222475428-063718c6-4228-4e14-8efb-cddaeb0cfa5a.mov
The log we got was from Pusher, but this is JS logic that only makes effect in web / desktop, it’s not related to Airship’s push notifications.
02-28 21:41:53.994 24278 24422 D ReactNativeJS: [info] [Report] Handled onyxApiUpdate event sent by Pusher - [{"onyxMethod":"merge","key":"report_4530354462045455","value":{"reportID":"4530354462045455","maxSequenceNumber":81,"lastVisibleActionCreated":"2023-02-28 21:41:54.465","lastReadTime":"2023-02-28 20:45:33.064","lastMessageText":":slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face:","lastActorEmail":"fabio.henriques+1@callstack.com"}},{"onyxMethod":"merge","key":"reportActions_4530354462045455","value":{"4605440722137264120":{"person":[{"type":"TEXT","style":"strong","text":"fabio.henriques+1@callstack.com"}],"actorEmail":"fabio.henriques+1@callstack.com","actorAccountID":14356954,"message":[{"type":"COMMENT","html":":slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face:","text":":slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face:","isEdited":false}],"originalMessage":{"html":":slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face::slightly_smiling_face:"},"avatar":"https://d2k5nsl2zxldvw.cloudfront.net/images/avatars/avatar_3.png","created":"2023-02-28 21:41:54.465","timestamp":1677620514,"reportActionTimestamp":1677620514465,"automatic":false,"sequenceNumber":81,"actionName":"ADDCOMMENT","shouldShow":true,"reportActionID":"4605440722137264120","isAttachment":false}},"shouldNotify":true}]
02-28 21:41:53.995 24278 24422 D ReactNativeJS: [info] [LOCAL_NOTIFICATION] Creating notification - ""

I also tried to disable our custom provider and listener here
public class CustomAirshipExtender implements AirshipExtender {
    @Override
    public void onAirshipReady(@NonNull Context context, @NonNull UAirship airship) {
        PushManager pushManager = airship.getPushManager();

        CustomNotificationProvider notificationProvider = new CustomNotificationProvider(context, airship.getAirshipConfigOptions());
        //pushManager.setNotificationProvider(notificationProvider);

        NotificationListener notificationListener = airship.getPushManager().getNotificationListener();
        // pushManager.setNotificationListener(new CustomNotificationListener(notificationListener, notificationProvider));
    }
}

But it doesn’t make difference about the problems, we are still going to get the truncated text and don’t receive the notification with a lot of emojis.
From my understanding, the problem is not in the library or our custom provider, it’s before the notification hit the device (or not hit, like the Test 4). Even debugging some library’s methods, it all seems fine to me.

Airship's team told us that it could be a issue with the size of our payloads. FCM payloads have a 4000 byte limit, and the payload from Test 1 has almost 2k bytes. I took this payload and replaced every "Test" occurence with "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum." in order to reproduce what could be the payload from Test 2, and this payload ended up with more than 4k bytes, which could explain why the large message (Test 2) didn’t work properly.

Airship's team told us that it could be a issue with the size of our payloads. FCM payloads have a 4000 byte limit

@fabioh8010 I've tested long plain-text payloads and they always worked (comes truncated). The problem is in symbols that are encoded as unicode (not only emojis) see my report https://github.com/Expensify/App/issues/14715#issuecomment-1426256907 . I've counted the maximum symbol amount that works correctly: 38 UTF-16 symbols. If you add some plain ascii symbols in the end - the message would be truncated and would come as push message.

@fabioh8010 You are describing payload being sent to Expensify API. I think someone from Expensify backend team should confirm that the same payload is being sent to Airship. (@tgolen ?)
You can try and send up to 15000 symbols in plaintext in a message and it would work, the truncated push would come, so the problem is in the Airship truncation mechanics.

Hi @alexxxwork, these payloads are what the mobile application receives when we receive a notification. We use the information from these payloads to customise Android's notification here and to handle its data when it's received or tapped here

Not overdue, we're working on it

I started by looking through our backend notification logic. First of all, the quote message issue is caused by internal logic that I'm not sure needs to apply to NewDot. I'm looking into this first as it will help me to resolve this related internal issue (Android notification grouping).

Nuked Android Studio, problem solved...
I've been debugging both the backend and Android and we have some options for reducing payload data. First I'll roll back the initial limit we had previously set to fix the quote issue, then I'll work on further reducing the payload.

First of all, the quote message issue is caused by internal logic that I'm not sure needs to apply to NewDot.

@Julesssss Could you confirm that ...'' ending is coming from E/App backend and has nothing to do with Airship? I thnik I should close the issue, opened in Airship about this bug.

@alexxxwork yeah the ellipsised message is 100% our internal issue. Please go ahead and close the airship bug.

I'm making good progress here, but the changes are slow to test as I need debuggable release builds which are slow to compile. I'm working with Ryan from Airship to help increase our payload allowance in a few ways:

Increasing our 2kb limit to 3kb+
Removing payload data that is not necessary for NewDot
Ignoring some of the Airship fields that we can reconstruct natively from the onyxData

We'll need to deploy the APP PR first, to ensure as many users are migrated to the new onyx data source before we deprecate fields that the app currently relies on

Ryan from Airship has gone one step further and is going to provide a way to gzip our payload, reducing the size by a decent amount!

Amazing!

PR in review

Actually, the PR is just one of a few PRs necessary to completely resolve this one

IN PROGRESS

The first PR has just hit prod, more changes are incoming.

Nice, not overdue, still moving

@Julesssss, @dylanexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

@Julesssss, @dylanexpensify Huh... This is 4 days overdue. Who can take care of this?

No update, the notification issue is still outstanding.

This issue has not been updated in over 15 days. @Julesssss, @dylanexpensify eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

Held because Manual Requests is super critical for EC3 and we're at risk of not being ready. Will be returning to this after.

@Julesssss shall we get this back to daily now?

Sorry I'm still insanely busy with Manual requests bugs. Aiming for next week

I'm heading OOO tomorrow for about a week so adding another BZ member while I'm away to help keep the train moving! 🚂  Thanks @jliexpensify!!

Okay, back on this today.
Setup steps for debugging Android notifications

Enable debugging
Replace the production Airship keys with debug
Create an Android release build from Android studio

Notes
Small messages are correctly retrieved, handled, and threaded.
At a certain point (once the message payload exceeds the current ~2kb limit, we strip onyxData from the payload data, and we fall back to the default notification styling (no threading).

It is extremely easy to hit the current 2kb limit, a message of just 15 characters triggers the onyx data to be stripped from a group chat message.

Message
payload size (kb)

1 char
1899

15 char
1994

50 chars
2242

500 chars
4977

What is causing us to exceed the payload limit?
Here's a breakdown of a few example notifications. As a reminder, any fullsize over 2000 is being removed from the notification payload

Example
payload size (kb)

10 chars

10 emoji

100 chars

500 chars

1000 chars

Notice that the reportAction is roughly 40+% of the payload, this is not used in NewDot!
We are supposed to first try to remove the reportAction, but this doesn't appear to be working

I went a bit further and sized up the individual onyxData fields:

For newDot, we can completely drop reportAction for an immediate 40% increase as it is a duplicate of data already included in the onyxUpdate
Within the Onyx update, message and originalMessage are the largest fields by far, followed by person, lastMessageText, and avatar

Example
payload size (kb)

100 chars

500 chars

1000 chars

Here's a WIP Pr for solving tasks 1 and 2.

I didn't have much time for this after the mobile deployer duty today, but I was able to resolve some style/psalm issues and applied some change suggestions form the WIP PR.
I also prepared custom iOS and Android builds so that I can verify the Web-E changes tomorrow.

Awesome, I'm seeing great results from solutions 1-3 listed above...  once we start zipping the payload we'll have an even larger message length limit:
https://github.com/Expensify/App/assets/10736861/fcd42440-aa5d-4c0e-b138-b4cfc26b305c

Here are the results of our first improvements. Notifications for messages up to roughly 980 chars in length will now persist the message successfully into onyx, up from 25!

Example
old size (b)
old wasPersisted (x < 2000)
new size (b)
new wasPersisted (x < 3500)

10 chars
1869
✅
1256
✅

10 emoji
2639
❌
1794
✅

100 chars
2490
❌
1600
✅

500 chars
4884
❌
2803
✅

1000 chars
7890
❌
4303
❌

The first PR resolved issues https://github.com/Expensify/Expensify/issues/286640 &
https://github.com/Expensify/Expensify/issues/286641
Continuing with improved logging next

I think we could close this one now. We'll create follow up issue for further improvements, but the major issue has been resolved.

@alexxxwork thanks for your help so far. We're going to take this internal and work with Callstack and Airship to resolve this given that it has gone 4+ weeks, but we'll be compensating you for your help so far

@cead22 It this issue still eligible for compensation?

@cead22 @dylanexpensify I'm the external reporter for this issue.

@dylanexpensify could you please pay out the reporting bonus and 'compensation' based on this comment please.
Sorry all, I have been working on similar issues for a while and didn't realise it was initially raised externally.

Upwork job here!
@priya-zha please apply for reporting!
@alexxxwork please apply for the work you've done for $500!

@dylanexpensify Proposal submitted. Thanks.

@dylanexpensify applied, thanks

@alexxxwork offer sent!

@dylanexpensify is this paid out? If so can we close it please

Done!


[FLOC-1979] Client certificate instructions that work on OS X

Fixes https://clusterhq.atlassian.net/browse/FLOC-1979
The tabs appear to not render correctly in the branch as-is.  If someone knows how to fix that, I'd love to know (or just check it into the branch).  If not, then I guess we'll drop the tabs and just have one section after the other.
I also added a link to this section of the docs from the other section about certificates since the other section leaves the user hanging.
I also didn't add any instructions about the pkcs12 export password.  Possibly I should have?

Cheers for picking this up JP
@alicesowerby Could you take a look at http://build.clusterhq.com/results/docs/curl-on-osx-FLOC-1979/build-7940/reference/authentication.html#li-os-x, and let us know what you think about having tabs in the documentation from a UX point of view?
My view is that this would be an excellent way of reducing the amount of scrolling and searching, but its something we'd need roll out across the whole site. As it stands, this would be the only tabbed section (that I know of) in the docs, and I'm also not sure we've enough time to get it working correctly.

Possibly I shouldn't have spent the time, but I tracked down the cause of the tabs not working and fixed it.  You can see them operating properly on the most recent docs build, http://build.clusterhq.com/results/docs/curl-on-osx-FLOC-1979/build-7985/reference/authentication.html

As it stands, this would be the only tabbed section (that I know of) in the docs, and I'm also not sure we've enough time to get it working correctly.

The old (current) getting started guide uses them, of course. :wink:
Please let me know if we should go ahead with this or revert to a one-after-the-other style for this section.

As I commented previously... When we have a defined problem to solve and that problem has been prioritised I am happy to do the UX/interaction design to solve it. AFAIK this has not been prioritised as a problem at this point in time and therefore I support Dave's implied position of leaving this until we can do it properly and in a considered manner.
FWIW it's probably a good solution to a probable problem :)

I would recommend reverting this to one-after-the-other style for this section, as this matches the continuity of the rest of the docs.
I really like this feature though, and have created FLOC 2251 to keep track, and post v1 @alicesowerby and I can do a full UX design, and it would then be rolled out across the site.
Thanks JP

Unhappy that the decision is to do more work for probably a worse result - but okay, here I go.


Harmless system DT prep work

A collection of fixes, enhancements, and clean-ups to our python-devicetree package that I made while working on a prototype for https://github.com/zephyrproject-rtos/zephyr/issues/51830.
I believe this is safe to merge now.

Addressed linter complaints.

Is there anywhere we can check about the python version? Not critical, but would be nice to say you need 3.6 or greater somewhere for dtlib.

We should pip install repo packages, so we can then use https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#python-requires. We actually have:
https://github.com/zephyrproject-rtos/zephyr/blob/4e0bc763edfeac6e2494187b4c02e5272995f49a/scripts/dts/python-devicetree/setup.py#L41
This works if added to one of our requirements.txt:
-e scripts/dts/python-devicetree

We have the bad habit of hacking Python path in most scripts, this would remove such need plus offer checks like Python version, dependencies, etc.

would be nice to say you need 3.6 or greater somewhere for dtlib.

Right, as far as the python devicetree package is concerned, what @gmarull said is true: we already have this declared in setup.py.


add github CI

I just started using this project and noticed potential for improvement. This is the first of a series of PRs. This PR adds a github action file that executes nix flake check for the main flake and the example flake. This workflow is automatically executed on every PR.
:warning: The maintainers of this repository may have to enable actions in the repository settings for this to work.
I tested this in a PR in my own fork https://github.com/m1-s/plasma-manager/pull/1/

Looks pretty good, nice work, and something I think would be welcome for the project. Only thing I am not sure about is if  Optional[str] is a lot better than str | None. From what I have gathered, in newer python-versions str | None is built in and if anything is the more "modern" way of typesetting optionals.

Looks pretty good, nice work, and something I think would be welcome for the project. Only thing I am not sure about is if Optional[str] is a lot better than str | None. From what I have gathered, in newer python-versions str | None is built in and if anything is the more "modern" way of typesetting optionals.

The only reason I made that change was because the python tooling complained about it. Can you clarify what you expect me to do here? I did not find anything about Optional being "built in".

I see. Not sure why the tooling would be complaining about it tbh as it to me seems like str | None is the "new" way of doing this kind of typing while Optional is more the old way of doing this (see: https://docs.python.org/3/library/typing.html#typing.Optional). In the end it doesn't really matter which of them we choose, they are equivalent after all, but I don't really think it needs changing at all.

I see. Not sure why the tooling would be complaining about it tbh as it to me seems like str | None is the "new" way of doing this kind of typing while Optional is more the old way of doing this (see: https://docs.python.org/3/library/typing.html#typing.Optional). In the end it doesn't really matter which of them we choose, they are equivalent after all, but I don't really think it needs changing at all.

Not sure why the tooling complained either. I created https://github.com/NixOS/nixpkgs/pull/290747/files which may be related.

OK, then this looks good to me. I reckon the python-typing thing should stay unchanged though so if you can revert this then I'll merge as soon as possible :). Good work!

It wont build without this change.

All right then, we can just change it, it really doesn't matter. I'll merge when I get home in a few hours


VerticalLinesEffect

A new Effect for Activate Power Mode
Vertical lines dash away up- or downwards, depending on upper- and lowercase, or symbols and numbers.
Spaces create two lines, one upwards, the oder downwards.
see gif here:
http://imgur.com/a/mn4yx

I really like these effects. I need time to think in the best way to allow packages/users to define their own custom effects and select them. When ready this, effects could be added by another external packages (I don't want to put more effects on the repository, but allow customization) or even for the user, hooking on some events probably.

see #11 and #108 for some attempts to achieve this

I read about power-mode a long time ago. For Hacktoberfest 2016, you need 4 Pull Requests on public repos. I saw #11 and thought it might be a good idea to add some more effects.
I didn't expect you to directly merge those, but instead show others what is possible. Reading the last character, reading the position of the cursor etc. So I hope that my work will somehow help to improve the effect aspect. Whatever that will become, an extensible system with an effect-market or just the power mode with another package where you load a bunch of effects at once. Whatever, I am looking forward to watch the developement of this package and atom.io.

hi @kyl3r92 take a look on the #264, your effects could be implemented as a plugins

Closing as now effect can be added with the new service
https://github.com/JoelBesada/activate-power-mode/wiki/Canvas-effects


In package @ibm-cloud/cloudant only the engine version is specified, there is no restriction regarding the npm version.
I see that your deployment is failing, but from the logs I cannot see any @ibm-cloud/cloudant specific entry.
By default the engine check is only warns the version mismatch. See engine-strict config, this way I suppose node-gyp might have some problem.

thanks , i will take a look into node-gyp as well\