msvc9_query_vcvarsall returns unicode strings on Python 2.7 64-bit and regular strings on 32-bit

msvc9_query_vcvarsall returns environment dict with keys "lib", "libpath", "include" and "PATH". On Python 2.7 32-bit values of this dict are regular strings, however on Python 2.7 64-bit this dict contains unicode strings. So when I later use this dict to update os.environ it throws an error:
TypeError: environment can only contain string

Not sure if this is a bug or not, if not you can close it. It's not a big deal for me, I already have it fixed in my code.

This function monkey patch distutils. I think it return, the unpatched function result in one case and in the patched function result in the other case.

It does seem like a bug. If Python 2.7 os.environ doesn't accept Unicode and msvc9_query_vcvarsall returns only strings in distutils, then the monkeypatch should probably also supply that interface for maximum compatibility.

I've pushed a fix for this issue. @cztomczak, can you copy the latest msvc.py module from master and confirm it fixes the issue in your environment?

Oh, and you'll need py27compat.py as well.

I've added comments to your commit, there seems to be a typo.

I am sorry, but this issue seems to be invalid and your commits should be reversed. I retested and msvc9_query_vcvarsall() returns unicode on both Python 2.7 32-bit and 64-bit. Previously I have been testing multiple Python flavors and must got confused somewhere on the way. The issue in my code with updating os.environ is still valid, as you can't update it with unicode strings on Python 2.7, however this is not an issue with setuptools. I have checked distutils query_vcvarsall() in distutils/msvc9compiler.py and this function calls str.decode("mbcs"), so it returns unicode strings. So looks like setuptools should be returning unicode strings as well. Again, sorry for causing the trouble.

However there is one bug in setuptools that I've noticed - but that's a separate issue. EnvironmentInfo().return_env() replaces unicode characters with its ascii equivalents. I've added "C:\Tęstą" to my PATH env variable and setuptools returned it as "C:\Testa" - which is an invalid directory. It's not an issue for me, but looks like a bug.


相对当前元素定位目标元素

When suggesting a feature, include:

As much detail as possible for what we should add and why it's important to Bootstrap
在BOOTSTRAP中许多操作元素和被操作元素相对固定，比如：collapse，操作collapse内容的按钮和被操作的collapse元素往往就是按钮的下一个兄弟元素。而现在，定位被操作元素往往使用jQuery Selector字符串。主要使用绝对定位，常常是用id选择器。这就常常要求手工编写id选择器。
另外，一些选项，如collapse.parent只允许设置selector字符串，而不允许设置为element，实际上，我查看了源代码，使用的是$(options._parent)，jquery的参数可不是仅限于字符串。
相对当前元素定位目标元素，是一个很符合逻辑、并且易于实现的技术。盼望能够尽快加上。

Relevant links to prior art, screenshots, or live demos whenever possible

from what I can gather with google translate, this sounds like a request for help with a specific implementation/use of bootstrap. i'd suggest trying stackoverflow or similar. see https://github.com/twbs/bootstrap/blob/master/CONTRIBUTING.md#using-the-issue-tracker

_getParent() {
  const parent   = $(this._config.parent)[0]
  const selector =
    `[data-toggle="collapse"][data-parent="${this._config.parent}"]`

  $(parent).find(selector).each((i, element) => {
    this._addAriaAndCollapsedClass(
      Collapse._getTargetFromElement(element),
      [element]
    )
  })

  return parent
}

the code of [data-parent="${this._config.parent}"] restrict the type of this._config.parent to string, but it is element or string is better than only string.

as data-parent would be an attribute coming from the HTML markup, it can't really be an element though

you are right, it is the problem. i look at some code, which is applied bs. there is a resolution that use guid() at target element, it is a little overweight.my resolution just need change
$(parent).find(selector)
as
$(parent).children([data-toggle="collapse"])


Demand maps for different times of day with public focus

Requested by: CAMPO-Alex
Date: 05/2022
Priority:
Additional details: Need additional clarification on this

CAMPO indicates they no longer need this.


Column typing validation + named inner types

Summary
@agorajek suggestions from https://github.com/DataJunction/dj/pull/290
validates map key types and allows named types for row. Row still has full support for any inner types including other nested complex types
>>> ColumnType.Row['int "number"'].args[0].name
'number'

Test Plan
unit tests

[x] PR has an associated issue: #https://github.com/DataJunction/dj/issues/291
[x] make check passes
[x] make test shows 100% unit test coverage

LGTM! One thing I noticed though is that the logical branches that raise a ColumnTypeError are all tested but I don't see any of the more boring tests for when the column type is instantiated correctly. Might be worth throwing a few of those in for good measure.

they are actually doctests https://github.com/DataJunction/dj/blob/b9da54c1315e528f5b6ae9d0830c8e53fd4a7d5c/dj/typing.py#L142

they are actually doctests

Very cool! Sorry, I missed that. We should probably be using doctests more throughout the codebase. :)


Implemented custom images

See issue #42
These changes follow option 1 on the issue and has
support for expansion as such: --docker-image {target}.
EDIT:: Reworked to work with Cross.toml instead

Thanks for updating the PR, @Emilgardis.
I'd rather not expose an easy way to use a different tag of the japaric/$TARGET image as e.g. tag v0.1.2 is not guaranteed to work with cross v0.1.1 and viceversa. And I definitely don't want an easy way for someone to use :latest with an stable cross release. No end user should ever use :latest as it is a moving target (it changes everytime a PR lands in master).
If you remove target.$target.tag, I'll r+.

Thanks again, @Emilgardis!
@homunkulus r+

:pushpin: Commit a32f4f0 has been approved by japaric

:hourglass: Testing commit a32f4f0 with merge 938efc9...

:sunny: Test successful - status-travis
Approved by: japaric
Pushing 938efc99dd2dd6c07fc1e4a1b6bcb23b9960e407 to master...


Panic on SetField with dynamicpb.Message types

What version of protobuf and what language are you using?
<EMAIL_ADDRESS>go1.18.0
What did you do?
Call SetField on a go type with a dynamic type.
https://github.com/emcfarlane/larking/blob/7767296b89b124569288fddcf0502ea38171c005/examples/library/main_test.go#L15-L34
func TestDynamicSet(t *testing.T) {
 	d, err := protoregistry.GlobalFiles.FindDescriptorByName("larking.examples.library.Book")
 	if err != nil {
 		t.Fatal(err)
 	}
 	md := d.(protoreflect.MessageDescriptor)
 	msg := dynamicpb.NewMessage(md)

 	req := &apipb.CreateBookRequest{
 		Parent: "/shelves/one",
 	}
 	x := req.ProtoReflect()
 	rd := x.Descriptor()
 	fd := rd.Fields().ByName("book")

 	v := protoreflect.ValueOf(msg)
 	x.Set(fd, v)  // Fails here

 	t.Log("x", x)
 }

As part of a PR to my project https://github.com/emcfarlane/larking/pull/55
Protobuffer is defined here: https://github.com/emcfarlane/larking/blob/7767296b89b124569288fddcf0502ea38171c005/examples/library/apipb/library.proto
What did you expect to see?
I expected the dynamicpb.Message to be converted to the Go type and set in the Field of the protobuffer.
What did you see instead?
Fails as type dynamicpb.Message doesn't equal the go type.
$ go test -v -run=TestDynamicSet
=== RUN   TestDynamicSet
--- FAIL: TestDynamicSet (0.00s)
panic: invalid type: got *dynamicpb.Message, want *apipb.Book [recovered]
        panic: invalid type: got *dynamicpb.Message, want *apipb.Book

goroutine 36 [running]:
testing.tRunner.func1.2({0x16f4220, 0xc0003695a0})
        /usr/local/go/src/testing/testing.go:1389 +0x24e
testing.tRunner.func1()
        /usr/local/go/src/testing/testing.go:1392 +0x39f
panic({0x16f4220, 0xc0003695a0})
        /usr/local/go/src/runtime/panic.go:838 +0x207
google.golang.org/protobuf/internal/impl.(*messageConverter).GoValueOf(0xc000369440, {{}, 0x17e6e40?, 0xc0003678c0?, 0x8?})
        /Users/edward/pkg/mod/google.golang.org/protobuf@v1.28.0/internal/impl/convert.go:458 +0x3f4
google.golang.org/protobuf/internal/impl.fieldInfoForMessage.func4({0xc000184e90?}, {{}, 0x17e6e40?, 0xc0003678c0?, 0xc0003678c0?})
        /Users/edward/pkg/mod/google.golang.org/protobuf@v1.28.0/internal/impl/message_reflect_field.go:445 +0xd0
google.golang.org/protobuf/internal/impl.(*messageState).Set(0xc000367900, {0x1928278?, 0xc0001c44b0?}, {{}, 0x17e6e40?, 0xc0003678c0?, 0x1da2220?})
        /Users/edward/pkg/mod/google.golang.org/protobuf@v1.28.0/internal/impl/message_reflect_gen.go:91 +0x10b
github.com/emcfarlane/larking/examples/library.TestDynamicSet(0xc0003981a0)
        /Users/edward/src/github.com/emcfarlane/larking/examples/library/main_test.go:31 +0x1c8
testing.tRunner(0xc0003981a0, 0x1856318)
        /usr/local/go/src/testing/testing.go:1439 +0x102
created by testing.(*T).Run
        /usr/local/go/src/testing/testing.go:1486 +0x35f
exit status 2
FAIL    github.com/emcfarlane/larking/examples/library  0.268s

Anything else we should know about your project / environment?

Go is strictly typed, so you cannot take the *dynamicpb.Message and use it as the concrete type that is the equivalent protobuf message.
You can fix this by using the strict type directly, instead of using a dynamic message. You should only use the dynamicpb when you do not have the concrete type available directly.

@puellanivis Yes the go types are different *dynamicpb.Message and *apipb.Book. I though the behaviour should be that protobuffer types are respected. Both types are the same underlying type proto type of larking.examples.library.Book.
Does the opposite fail of assigning a go type to a dynamic's type field?
If this isn't a behaviour issue please close! Thanks.
In my case, I've fixed this by looking up the MessageType before using dynamicpb, e.g.:
mt, err := protoregistry.GlobalTypes.FindMessageByName("larking.examples.library.Book")

Yes, trying to assign both ways between *dynamicpb.Message and *apipb.Book will fail because of the strict typing. I tried to look a bit for something that would convert *dynamicpb.Message into the concrete underlying type, but I don’t think it exists. The concrete type has to be compiled in, and dynamicpb is intentionally supposed to be much more flexible than that, so it would have to return an error in case the type were not concretely available anyways.
I’m kind of grasping around here, as I’m not deeply familiar with how dynamicpb all works.

Maybe the dyanmic protos could wrap the go type, if available? Then the types could be converted easily? I'm guessing this would have some edge cases with one-to-many relation of descriptors to descriptorTypes: https://pkg.go.dev/google.golang.org/protobuf/reflect/protoreflect#hdr-Go_Type_Descriptors
Closing, as I do think it makes sense to panic in this case.

Yeah, there might be some ways to get it working, but it might be a hefty amount of work to get it right.


Allow velox_hive_iceberg_test to support multiple delete files

Description
In velox/connectors/hive/iceberg/tests/IcebergReadTest.cpp, we covered the case where a single positional delete file contains rows from multiple base data files, but I didn't include the test for multiple delete files. We need to compose multiple delete files and add a new test case for that.

cc @agrawalreetika


Check for Dependancies

Cross operating system interoperability is a main goal for this project. Currently, this tool is designed and built for Kali Linux. It does not check for dependencies and therefore does not function as intended in other environments.
In pursuit of cross-os functionality, the first step is to define the projects dependancies.
This is a good first issue for hacktoberfest. To close the issue, review the tools used in the main python file and make a dependancies.txt file.

Can I take up this issue? Do I have to check automator_gui.py only for the dependancies.

Absolutely, it’s all yours if your up for it

Should I keep it in the main folder or a particular folder? Also, should I list the various command to install the dependencies for majorly used OS's? (I'm particularly new so I don't have much knowledge, so any kind of help is awesome)

What you sent in is a great start, thanks for the contribution!


Update context-menu opener style.

Coverage remained the same at 77.857% when pulling 5b25e08c11a0e2ace11fd62dcae518109f6644e1 on dbatiste/context-menu-opener-style into 1e190de4c4718be77544ad6c7ebd42218c8cfe71 on master.


Add Sentry integration

Add the ability to include a Sentry integration. https://docs.sentry.io/platforms/ruby/guides/rack/

Hu @duffn …
I would like to give it a shot

Oh my, thanks for your interest! I just happened to open a PR almost as the same time you posted! https://github.com/duffn/grape-api-boilerplate/pull/116
There is also an issue for making the requesting logging middleware optional if you'd be interested in that one? https://github.com/duffn/grape-api-boilerplate/issues/114
Again, thank you for showing interest!


Add gamepad rumble support to bevy_input

Objective
Provide the ability to trigger controller rumbling (force-feedback) with a cross-platform API.
Solution
This adds the GamepadRumbleRequest event to bevy_input and adds a system in bevy_gilrs to read them and rumble controllers accordingly.
It's a relatively primitive API with a duration in seconds and GamepadRumbleIntensity with values for the weak and strong gamepad motors. It's is an almost 1-to-1 mapping to platform APIs. Some platforms refer to these motors as left and right, and low frequency and high frequency, but by convention, they're usually the same.
I used #3868 as a starting point, updated to main, removed the low-level gilrs effect API, and moved the requests to bevy_input and exposed the strong and weak intensities.
I intend this to hopefully be a non-controversial cross-platform starting point we can build upon to eventually support more fine-grained control (closer to the gilrs effect API)

Changelog
Added

Gamepads can now be rumbled by sending the GamepadRumbleRequest event.

So, the failing Dependencies job... I'm not really sure why it fails. Is there something i need to do?
Otherwise, this pr is now ready as far as I'm concerned.

Nope: that needs another PR to address and isn't your concern. It won't block CI.

need to be careful about under/overflow on the f32 to u16 conversion.

Added some tests that should make sure nothing crazy happens.
I also changed how we call gilrs, so that framerate drops won't affect rumble durations.

We need to clamp in to_gilrs_magnitude still. Once that's resolved, this LGTM and I'll merge!

How so? As far as i understand it shouldn't be needed: https://github.com/rust-lang/rust/pull/71269
Or do you mean for clarity of intent?

Ah, TIL. Can we add tests for it instead then?

Ah, TIL. Can we add tests for it instead then?

There already are some ;)

I think a single line comment on the as u16 conversion in to_gilrs_magnitude saying "value is clamped by property of rust f32 to integer conversion" would avoid all future confusion.


EAU and EU enhancement

Presidential, nationalist and populist dictatorships can join EAU
any_neighbour_country replaced with any_country (Romania, Bulgaria, Armenia are real-life examples)
Allowed change regime event to democracy for all dictatorships. Allowed great power presidential dictatorship change regime event against democracies.

How do I create a .tga picture? It is a format of 3d printer models and does not open in my picture editor.

Note: probably must add year=1991 to potential in EAU, or a list of all possible post-Soviet countries + Mongolia

Mistake in a description
Khodorkovsky arrest event …
Allows to switch to presidential_dictatorship of course

I have merged the events - with some corrections - please use the Victoria
2 Validator to ensure that there are no typos.
On Sun, Dec 27, 2015 at 8:40 PM, VictorWeikum<EMAIL_ADDRESS>wrote:

Mistake in a description
Khodorkovsky arrest event …
Allows to switch to presidential_dictatorship of course
—
Reply to this email directly or view it on GitHub
https://github.com/simsulla/nwomod/pull/58#issuecomment-167437665.


Added focus intercepting input for Full style

Q
A

Bug fix?
[X]

New feature?
[ ]

New sample?
[ ]

Related issues?
fixes #52

What's in this Pull Request?
Added hidden input to intercept focus when PropertyFieldColorPicker is the first field in the property pane and the style is set to Full. Additional details can be found in issue #52

Thanks @thechriskent for the fix


Update all dependencies to the latest versions

All up to date: Update all depencies to their latest version to take advantage of all new features and functionality.

All dependencies were updated at the beginning of the project locally and were uploaded with the initial commit on 01.07.2023.


Use newly added colcon_core.logging.get_effective_console_level

The newly provided function replaces the private implementation carried here.
This PR should be updated to include the new version constraint when colcon-core is next released, so marking draft until then.

Does this PR need to increase the minimum colcon_core version to take this feature?

Yes it does:

This PR should be updated to include the new version constraint when colcon-core is next released, so marking draft until then.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 86.70%. Comparing base (aa1e317) to head (1851435).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #16      +/-   ##
==========================================
+ Coverage   86.44%   86.70%   +0.26%
==========================================
  Files           6        6
  Lines         177      173       -4
  Branches       30       28       -2
==========================================
- Hits          153      150       -3
  Misses         22       22
+ Partials        2        1       -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

This PR should be updated to include the new version constraint when colcon-core is next released, so marking draft until then.

I can read good 🤦🏼


fix refence.cnn file difference

FOR CONTRIBUTOR:

[x] I have read the CONTRIBUTING.md document and this tool is appropriate for the tools-iuc repo.
[ ] License permits unrestricted use (educational + commercial)
[x] This PR adds a new tool or tool collection
[ ] This PR updates an existing tool or tool collection
[ ] This PR does something else (explain below)

Yes, this will work, nice!


Build Readme file

Implement Readme :
Description
Installation
Technology
Database
Usage / Videos??
Contact me
License

Readme File completed - includes all informative areas


cargo local-registry --sync Cargo.lock vendor/ fails when .cargo/config is present

cargo local-registry --sync Cargo.lock vendor/ fails when .cargo/config overriding the crates-io is present:
[source.crates-io]
registry = 'https://github.com/rust-lang/crates.io-index'
replace-with = 'local-registry'

[source.local-registry]
local-registry = "vendor"

Potentially, something similar to this code in cargo-vendor is needed?

That fix works nicely unless except we need the source replacement to actually talk to crates.io (Our proxy blocks it as it doesn't end in '.git' like all the other gitlab repos do.)
Maybe we need to make this ignore either smarter or just configurable?

@gilescope - would you create a new issue with a little more detail rather than commenting on an old, closed issue please?


Kite incompatible with Pycharm 2019.3?

When I launch Pycharm it notifies me with this: "Plugin Error: Plugin "Kite" is incompatible (target build range is 181.0 to 192.*)."
(Pycharm community)

Hi there, Sorry for the inconvenience! We're working on this issue.
However, Kite is presently compatible with PyCharm/IntelliJ 2019.3. Please use the Kite Copilot desktop app to uninstall and reinstall the Kite plugin for PyCharm. Then manually enable Kite via PyCharm plugin settings. This should complete the update. Restart PyCharm in the event you're still not seeing it work.
We're also aware of a bug where Kite keeps on trying to update the PyCharm plugin after it has been updated. We'll post an update here once a fix is pushed for this bug, too.

Ok, it worked great. Thank you for the fast response.

Hi there, Sorry for the inconvenience! We're working on this issue.
However, Kite is presently compatible with PyCharm/IntelliJ 2019.3. Please use the Kite Copilot desktop app to uninstall and reinstall the Kite plugin for PyCharm. Then manually enable Kite via PyCharm plugin settings. This should complete the update. Restart PyCharm in the event you're still not seeing it work.
We're also aware of a bug where Kite keeps on trying to update the PyCharm plugin after it has been updated. We'll post an update here once a fix is pushed for this bug, too.

nice. I have tried and my problem is done!


BUG: run tests in a tempdir, copy needed local files

When ready, will fix gh-101
(edited)

With cda3e8b94ee798b276c213a5a8c55949e7680556, gh-101 seems to be gone.

Two things I do not understand ATM:

the path to local files in test_testmod is clearly wrong. Why does TestLocalFiles pass with the doctest layer?
in test_pytest_configuration, who filled the local_resources dict of dt_config?

Two things I do not understand ATM:

the path to local files in test_testmod is clearly wrong. Why does TestLocalFiles pass with the doctest layer?
in test_pytest_configuration, who filled the local_resources dict of dt_config?

I believe the local_resources attribute is updated in the local_file_cases module here: https://github.com/ev-br/scpdt/blob/a79e6465b52a30b57db36dc4fa0ab3820ea08c37/scpdt/tests/local_file_cases.py#L5
However, the local files are typically located in the same directory as the module referencing them so the values should just be the names of the file:
dt_config.local_resources = {'scpdt.tests.local_file_cases.local_files':
                                  ['local_file.txt'],
                            'scpdt.tests.local_file_cases.sio':
                                  ['octave_a.mat']
                                  }

I pulled this branch locally and this slight change seems to work.

Could you send your changes as a PR for the CI to run?

That seems to have done the trick: https://github.com/ev-br/scpdt/pull/127
Can I push the commit to this PR so that I can close the one I just created?

Yup sure, if that's more convenient.

Yup sure, if that's more convenient.

Actually, I'll cherry-pick it and squash my debug commits.

Yup sure, if that's more convenient.

Actually, I'll cherry-pick it and squash my debug commits.

😅  too late

OK :-).
Pulled, squashed, and pushed to here. CI is green.

Merging in. Thank you Sheila for the fix!


Customization

Number of "knocks" to trigger event.
Minimum and maximum time interval allowed between "knocks" to trigger a single event.
Time interval allowed between "knock events".
"Z" variation needed to recognize a knock (Considering cartesian coordinates (X, Y and Z ) and accelerometer data, the Z variation is related to the oscillation of the phone when the user "knocks" it).

We'll have to create separate issues later, but for right now, let's keep them organized here

public properties for customization

Done with the properties below:

limitDifference
numberOfKnocksNeeded
minimumTimeBetweenSingleKnocks
maximumTimeBetweenSingleKnocks
timeNeededBetweenKnockOperations


homebrew cask

hey,
would it be possible for you to create a homebrew cask for it? there is something I've created, perhaps you'd want to manage that closer to the source (meaning your repo)?
https://github.com/avoidik/homebrew-eloston-chromium-signed?tab=readme-ov-file
cheers

+1

Hey @avoidik,
I currently don't have time for this (sorry!), but feel free to publish this yourself! One note, though, is that over time, there is a chance that this repo might be deprecated in favor of officially signed builds from @Cubik65536

xref. https://github.com/ungoogled-software/ungoogled-chromium-macos/issues/184


SESA-1320: Fix broken string subtypes in 1.0.0-rc.2

Five of the subtypes in the 1.0.0-rc.2 schema are missing the type field specifying string_t. This is fixed in later versions of the schema.
These missing super-type attributes, besides being technically incorrect, lead to invalid JSON Schema for classes that use attributes of these types.
Since RC2 can no longer be changed, we add the missing attributes here in the Splunk extension. Fortunately this works.
As an exercise for reviewers, you can look at the dictionary.json of the 1.0.0-rc.2 schema branch and compare that to later versions of the schema to see these type fields added. You could even run the OCSF Server with rc2 and this MR's Splunk extension, then download a JSON Schema like for account_change class (as an example), and see the lack of file_hash_t and subnet_t in the "fixed" JSON Schema.

Will this be the only change that corrects the individual json files or possibly a further MR will be added to fix the individual json schema's

The updates from this PR were added on this test server for folks to check out before we approve and merge.


Ensure in compile time that Borer serializer is used for every message, event and persistent state

Since methods like ask/? and tell/! do not accept any implicit codec param, instead resolving the (de)serializer for messages at runtime ://
Thus it's still perfectly possible that even if Borer serializer is present in config, it still doesn't cover all classes that are used as messages/events/state. For some of them, either Java serializer may be used as a fallback, or, if that's disabled, just an exception thrown.
Currently, using ArchUnit, we're checking whether type params of all Behaviors, ReplyEffects etc. present in method return types are extending CborSerializable... but that's pretty awkward. A more proper solution should check that in compile time rather than in tests using reflection :/

@MarconZet I think you can take this as the next priority, given that we got discouraged from delving into #7 🤔

Not sure how this can be achieved tho... compiler plugin maybe? 🤔

Pls start with runtime-reflection-based solution, similar to what's currently in ArchUnit (but without using ArchUnit as a dependency):
  // The below tests (roughly) check that the classes used as messages/events/state in Akka
  // are always marked as CborSerializable, to ensure that Jackson CBOR and not legacy Java serialization
  // is used for their serialization.
  // For Akka to ensure that condition statically, a major redesign would be necessary -
  // all methods like `ask`, `tell`, `Effect.persist` etc. would need to require an implicit `Codec` (?) parameter.

  // The below tests do NOT ensure that the Jackson serialization of messages/events/state will actually succeed in the runtime.

  "Messages, events and entity state classes" should {
    "implement CborSerializable" in {
      classes
        .should(new ArchCondition[JavaClass]("only use CborSerializable message/event/state types") {
          override def check(clazz: JavaClass, events: ConditionEvents): Unit = {

            clazz.getAllMethods.asScala.foreach { method =>
              def checkType(tpe: Type, category: String, failsWhen: String): Unit = {
                tpe match {
                  case clazz: Class[_] if clazz.getPackageName.startsWith("akka") =>
                  // OK, acceptable

                  case clazz: Class[_] if clazz == classOf[scala.Nothing] =>
                  // OK, acceptable

                  case clazz: Class[_] if !classOf[CborSerializable].isAssignableFrom(clazz) =>
                    val message =
                      s"Type ${clazz.getName} is used as Akka $category (as observed in the return type of method ${method.getFullName}), " +
                      s"but does NOT extend CborSerializable; this will fail in the runtime $failsWhen"
                    events.add(SimpleConditionEvent.violated(clazz, message))

                  case _ =>
                }
              }

              val returnType = method.getRawReturnType
              val genericReturnType = method.reflect.getGenericReturnType

              if (returnType.isEquivalentTo(classOf[akka.persistence.typed.scaladsl.ReplyEffect[_, _]])) {
                genericReturnType match {
                  case parameterizedType: ParameterizedType =>
                    val Array(eventType, stateType) = parameterizedType.getActualTypeArguments
                    checkType(eventType, "event", "when saving to the journal")
                    checkType(stateType, "persistent state", "when doing a snapshot")
                  case _ =>
                }
              } else if (returnType.isEquivalentTo(classOf[akka.projection.eventsourced.EventEnvelope[_]])) {
                genericReturnType match {
                  case parameterizedType: ParameterizedType =>
                    val Array(eventType) = parameterizedType.getActualTypeArguments
                    checkType(eventType, "event", "when saving to the journal")
                  case _ =>
                }
              } else if (returnType.isEquivalentTo(classOf[akka.actor.typed.Behavior[_]])) {
                genericReturnType match {
                  case parameterizedType: ParameterizedType =>
                    val Array(messageType) = parameterizedType.getActualTypeArguments
                    checkType(messageType, "message", "when sending a message outside of the current JVM")
                  case _ =>
                }
              }
            }
          }
        })
        .check(importedProductionClasses)
    }
  }

^ This is very suboptimal since e.g. it can't ever check the type of objects passed to tell/ask though :/


Add check for mod_expires in the api .hraccess

This check was already in the top-level .htaccess but not in the one under api/

That Codacy thing does not look properly configured

Are you re-commiting this pull ? I just ran into the same problem and had to fix the .htaccess as well.

@mbasaglia Codacy is setup to work with the re-write branch. You can safely ignore it here for now.

I changed the base branch for the request, but can't re-open it.


[HOLD for payment 2023-02-22] Blank screen appears tapping Start Over to continue to manual step

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:

Login with any account
From LHN, open Workspace, make sure you already enter your bank account informations manually before.
Click on Start Over button, notice the background is empty, now close that modal

Expected Result:
If user close Start Over modal, it should stay at that screen and the background behind modal shouldn’t be blank when modal is opening.
Actual Result:
It still continues to Bank Account Manually steps after closing modal and the background of screen when opening modal is empty
Workaround:
unknown
Platforms:

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

[ ] iOS / native

Version Number: v1.2.62-1
Reproducible in staging?: y
Reproducible in production?: Could not test
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/215806517-8399d4f6-99e1-4938-a2d4-db391ff07fa5.MP4
https://user-images.githubusercontent.com/43996225/215806673-d69336f6-d312-4e4f-931c-f8acfd0db070.MP4
Expensify/Expensify Issue URL:
Issue reported by: @hungvu193
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1674797406896359
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01b3c30fe0a5c6a556
Upwork Job ID:<PHONE_NUMBER>894618624
Last Price Increase: 2023-02-01

Seems super similar to this issue, which is also in the VBA flow and launching a modal: https://github.com/Expensify/App/issues/14566

In the meantime, I can reproduce this consistently on iOS native v1.2.62-0
https://user-images.githubusercontent.com/16232057/215921649-4759efe6-c356-4d83-ae9b-5b5e37efa065.MP4

I'm always a bit wary of sending anything in this flow external before a hip check, so adding the engineering label for a second pair of eyes before then.
Also, cc: @MariaHCD @nkuoch @ctkochan22 as resident experts in this domain! :)

Looking into this, I think the root cause for this issue and https://github.com/Expensify/App/issues/14566 is the same.
Because we return the WorkspaceResentBankAccountModal here, we're inadvertently hide the Continue with setup form leading to a blank screen.
I think I can draft up the fix for this. Hope you don't mind @cristipaval!

I have a draft PR here: https://github.com/Expensify/App/pull/14726
Just need to test on all platforms and fill out the author checklist.

@MariaHCD, @trjExpensify, @rushatgabhane Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

Pr is in review, Melv.

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

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

https://github.com/Expensify/App/pull/14726

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

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

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

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

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

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

@rushatgabhane I've sent you an offer for $1k for the C+ review, @hungvu193 $250 for the bug report. Let me know when you get a sec to accept!

[@rushatgabhane / @MariaHCD] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
I think the issue was it was a big refactor PR and we'd missed testing the Start over feature. Not really sure if we need another other steps here.

I agree with this btw. We do have Start Over in the regression test suite now, so this should be sufficient. Checking these off!

Thanks @trjExpensify , I accepted the offer

📣 @hungvu193! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

Alrighty, payments have been made. Thanks all!

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~01ff54c35a1f76441a

⚠ Invalid email. Please make sure to create an Expensify account with this email first here.

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~01ff54c35a1f76441a

✅ Contributor details stored successfully. Thank you for contributing to Expensify!


Stuck in check point for 12 hours

Hi,
I am doing a large graph computation using multiple threads. I create two fht's, one for storing and other for indexing. All the threads use a singleton class to interact with the store. The singleton class exposes methods to create, RMW, read etc. The singleton class spawns off a thread that takes a snapshot of the two FasterKV's I am using. All the methods in the class wait for the checkpoint to finish. So, if there is a checkpoint going on and a thread calls one of the methods in the class, it will wait because the first two lines of every method is:
            fht1.CompleteCheckpoint(true);
            fht2.CompleteCheckpoint(true);

Each object stored is almost 1KB in size. I am printing entry count when we start snapshot. As you can see it is fairly large (this is after 15 minutes of computation). Is this the reason why the program is stuck for 12 hours, all threads waiting for computation to finish?

            73849447-4c68-4dd1-bc87-d145174401fb
            fht1 Snapshot started: 1282531
            fht2 Snapshot started: 70292

To add, I checked the snapshot folder and there is a 100KB file created with the name snapshot.dat.obj.log It was in this state for a lot of time without being updated.

You do not really need to wait for checkpoints to complete before issuing operations. FASTER can handle requests while checkpointing is going on. All you need to ensure is that NEW threads don't register themselves with FASTER while checkpointing is actively occurrining.
That said, I cannot think of a reason why the snapshot should take so long. You might try disabling one of the two instances to see if that helps. Is it possible to create a simple stand alone repro that demonstrates the problem? Also adding @gunaprsd for providing other suggestions.

Also, you need to make sure no thread is sleeping or doing stuff without periodically refreshing by calling fht.Refresh().

Thanks @badrishc
I have created the below gist that is not exactly using the same object as I out int he store. But I am using the same thread access pattern. I modified the example in the documentation. The issue repro's. It is taking checkpoint and never finishes.
https://gist.github.com/somecoder2019/a99cb4721fb9444ac272ace8af017ee0

First of all, thanks for the simple and excellent repro!
The problem is that you are not periodically calling refresh from session threads. Refresh is the mechanism threads use to report forward progress to the system. If you change the inner loop, in both RunSession() and ContinueSession(), to the below, it will work:
 if (seq % 1024 == 0)
{
    fht.Refresh();

    if (seq % 65536 == 0)
    {
        fht.CompletePending(false);
    }
}

A couple other side notes:
(1) As a heads up, you may need to use a better 64-bit hash/comparer for keys in future if you run into performance issues:
public struct LongComparer : IFasterEqualityComparer<long>
{
    public bool Equals(ref long k1, ref long k2) => k1 == k2;
    public long GetHashCode64(ref long k) => Utility.GetHashCode(k);
}

fht = new FasterKV<long, long, long, long, Empty, Funcs>
            (..., comparer: new LongComparer());

(2) You can kill your program, change Run() to Continue() and perform recovery. However, the local variable fullCheckpointToken will be lost on recovery. You can either choose a particular recovery token from storage, or simply ask FASTER to use the latest recovery token as follows:
fht.Recover();

I ran the recovery code path and verified that it works as well, and resumes session 1 at a particular offset.

Thanks @badrishc. That solved the issue for me.
I am hitting a different issue with serialization and deserialization but will open a separate issue.

You might also try the "readcache" branch, that has some bugfixes related to serialization.

Will do. Thanks.


New: Add prefix support to be able to specify a custom Prometheous metric name prefix

https://github.com/UNIwise/socket.io-prometheus-metrics/issues/12
I've done this on the v2 branch since that seems to be were the development is - I hope that is okay.

The pull request contains the dist/ directory which should not be included.

I think this code might be a better fit for the v2 branch. Would you please look into adding this to v2 instead?
Also thanks a lot for you interest in the project!

Hi - thanks for your replies! This was targeting the v2 branch - have I not set the pull request up properly to reflect that?
Regarding the dist directory - the package.json references "main": "./dist/index.js",. So to be able to npm install this package and then use it, the dist directory would need to be included. The source is TS, so it couldn't be directly referenced from package.json and have it work without tsc.

My bad you did indeed target the v2 branch!
The package is meant the be build and published to npm so this repo does itself not hold the build.

Sorry for quite getting it - when you npm install socket.io-prometheus-metrics it will pull in the contents of this repo (I'm assuming the v2 branch here) - then if you do a require('socket.io-prometheus-metrics') it will fail since dist/main.js isn't present.

No, when doing running npm install the client fetches a tarball from the npm registry with the released package and extracts it into node_modules/<package name>.
You can find links to the tar ball and inspect it yourself by running npm view as so:
npm view socket.io-prometheus-metrics

<EMAIL_ADDRESS>| Apache-2.0 | deps: 3 | versions: 7
Prometheus metrics for socket.io

keywords: prometheus, socket.io, metrics

dist
.tarball: https://registry.npmjs.org/socket.io-prometheus-metrics/-/socket.io-prometheus-metrics-1.0.6.tgz
.shasum: 59189d57daaa879708a76d6618cc0bbef87fc9a0
.integrity: sha512-rG1XIWuFRysVE/VE2ikJcYbv1ZqcY5IZ5CJOoih2MMiVx7GujwvxF1olcpDlQ/iGGryCXC/FRoBAB00Qnzsntw==
.unpackedSize: 24.3 kB

dependencies:
express: ^4.16.4     prom-client: ^11.2.1 socket.io: ^2.2.0

maintainers:
- jenkinsuniwise<EMAIL_ADDRESS>- jonastranberguniwise<EMAIL_ADDRESS>- mads_stenhoj<EMAIL_ADDRESS>
dist-tags:
latest: 1.0.6

published 3 months ago by jonastranberguniwise<EMAIL_ADDRESS>
When releasing a package the application is build and then the npm publish command is executed, packaging all the files (including the dist folder) in a tar and pushing it to the npm registry. Thats why there is no need for the dist folder in version control. In general compiled code should not be version controlled.


UDP is a Legacy winston transport.

Please tell us about your environment:

winston version?

[ ] winston@2
[X] winston@3

node -v outputs: 10.15.0
Operating System? macOS
Language? ES6/7

What is the problem?
The "problem" is that Winston tell us UDP is a Legacy winston transport. Consider upgrading: https://github.com/winstonjs/winston/blob/master/UPGRADE-3.0.md
But that webpage contains no information about UDP (and we are already using Winston v3).
What is the correct way to use an UDP transport? Or the correct alternative to that transport nowadays?
Other information

Thank you!

Hello, any news on this?


Time capsule #446

The Time Capsule Web App is an innovative platform that allows users to create, store, and share digital time capsules. Users can contribute memories, photos, videos, and messages intended for future retrieval, fostering a unique connection between the past and the future. The app features a user-friendly interface for easy navigation and allows users to set specific future dates for when their capsules can be opened.
Key features include:
1)User Authentication: Secure sign-up and login for personalized experiences.
2)Capsule Creation: Users can create capsules by adding text, images, videos, and documents.
3)Scheduled Release: Users can specify a future date for capsule unlocking, creating a sense of anticipation.

@suryanshsk why was this closed??

This is not related with Python Voice Assistant projects


Fix NVP_HOLD_USE_EXPLAINED useOnyx wrong config

Details

There is a wrong config being set for NVP_HOLD_USE_EXPLAINED in MoneyRequestHeader. This PR fix it.
Fixed Issues

$ https://github.com/Expensify/App/pull/42334#discussion_r1620112799
PROPOSAL:
Tests

Same as QA Steps

[x] Verify that no errors appear in the JS console

Offline tests

Same as QA Steps
QA Steps

Prerequisite:

have a money request and hold it
Confirm the hold education modal

Steps:

Go to the on-hold transaction
Verify there is no hold education modal shown because you already confirm it before
Refresh the page (only on web)
Verify there is no hold education modal shown
Repeat 3-4 a few times

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/50919443/d71c76de-c262-46ee-9c75-19923982c3e3

Android: mWeb Chrome

https://github.com/Expensify/App/assets/50919443/de7235c9-732d-4871-834e-26c1975d0268

iOS: Native

https://github.com/Expensify/App/assets/50919443/3b26ec6c-e1e5-412f-b2f6-1dffbc757fbb

iOS: mWeb Safari

https://github.com/Expensify/App/assets/50919443/ecf264d2-896a-452f-89c1-5dff3de50ff4

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/50919443/91ee1760-5229-4323-9e22-50adee4660e4

MacOS: Desktop

https://github.com/Expensify/App/assets/50919443/e70459a7-4ee5-4ebc-b6fc-bfe0cf156546

@techievivek fyi, this is a follow up from https://github.com/Expensify/App/pull/42334

@bernhardoj The current bug: When you first load the page, the hold education modal will appear for a bit and then close automatically. Because shownHoldUseExplanation is initially undefined

Thanks, I can repro it and have added the test step and recordings.

@DylanDylann sorry, just to confirm, you are going to review this one, right?

Gentle bump @DylanDylann to review the PR.

Whoops, I missed this PR. Sorry

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@bernhardoj Could you explain why we should remove initial value of shownHoldUseExplanation? We need to ensure that it doesn't break any other flows

Oh, thanks. LGTM 💯

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@bernhardoj The popover still displays for the first time going to the transaction report after login again
https://github.com/Expensify/App/assets/141406735/3246f019-5078-4073-bf3c-9971139a1557

NVP_HOLD_USE_EXPLAIND is saved locally only, so if you log out or switch devices, the value is false. You can check the value in the storage.

https://github.com/Expensify/App/assets/141406735/58f41c53-609e-4193-a35a-cc93aca5429e
@bernhardoj

The NVP_HOLD_USE_EXPLAIND onyx value, not the loading state. It's either false or empty.

@bernhardoj  I don't understand your mean

If you relogin, NVP_HOLD_USE_EXPLAIND doesn't exist on onyx, so the hold modal shows again.
https://github.com/Expensify/App/blob/66cd70716217b91c927d5267f7672b1d080ac17f/src/components/MoneyRequestHeader.tsx#L174-L176
so isOnHold && !shownHoldUseExplanation becomes true.

The NVP_HOLD_USE_EXPLAIND onyx value, not the loading state. It's either false or empty.

holdUseExplained doesn't exist on Onyx

@techievivek All yours

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to production by https://github.com/mountiny in version: 1.4.83-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅