HPHX-6481: Switch lang does not work the first time

Description
Please include a summary of the change or which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

@testradav @mikeangelsilva please review this PR

@testradav @mikeangelsilva please review this PR

@testradav @mikeangelsilva please review this PR

adding @mandeepalluru as we need a core voltmx dev reviewer involved


Remove old documentation site

The old Heptio quickstart documentation site is still live.  We should make tear down that content and probably redirect to a new location.  Will need to work with SRE to make necessary changes.

That isn't really owned by this project.  ping @thrawn997


[dev.fuzz] cmd/go: respect -cpu=n on workers.

What version of Go are you using (go version)?

λ gotip version
go version devel go1.17-5542c10fbf Fri Jun 4 03:07:33 2021 +0000 windows/amd64

Does this issue reproduce with the latest release?
Tip branch build. Fuzzing not in latest release.
What operating system and processor architecture are you using (go env)?
go env Output
λ gotip env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=d:\temp\gocache
set GOENV=C:\Users\klaus\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=e:\gopath\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=e:\gopath
set GOPRIVATE=
set GOPROXY=https://goproxy.io
set GOROOT=C:\Users\klaus\sdk\gotip
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Users\klaus\sdk\gotip\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=devel go1.17-5542c10fbf Fri Jun 4 03:07:33 2021 +0000
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=d:\temp\wintemp\go-build102784969=/tmp/go-build -gno-record-gcc-switches

What did you do?
Run fuzz test which has a concurrent component, or pretty much any fuzz test.
with λ gotip test -fuzz=. -test.run=None -parallel=16 -cpu=2.
What did you expect to see?
I would expect each worker to have runtime.GOMAXPROCS(2) similar to how tests and benchmarks behave.
Arguments could be made for workers defaulting to runtime.GOMAXPROCS(1), but I would at least like the option to change it easily.
What did you see instead?
Each worker has default GOMAXPROCS, leading to significant CPU overprovisioning and workers fighting for CPU threads.

/cc @jayconrod

Each worker is essentially single threaded, but I guess if the code being fuzzed is doing parallelized work it could lead to resource contention. Based on my experience I've only seen a drop in performance when I set -parallel > the number of available threads.
We could default each worker process to use runtime.NumCPU()/parallel CPUs. Allowing the user to set their own limit seems reasonable.

We could default each worker process to use runtime.NumCPU()/parallel CPUs. Allowing the user to set their own limit seems reasonable.

@rolandshoemaker parallel makes no sense, that is mixing apples and oranges.
It currently uses the default, which I argue also doesn't make much sense, or at least should be controllable by the existing -cpu parameter on tests, so you can run fuzz tests with different GOMAXPROCS settings.

@rolandshoemaker parallel makes no sense, that is mixing apples and oranges.

Why not? parallel controls the number of workers. If we want to prevent significant thread contention by default we can set each worker to use number of threads / number of workers threads. This should be user tunable, but we also need to set a reasonable default.

@rolandshoemaker I misread your / as "or" (language meaning), not "divided by".
In my view -paralllel controls the number of worker processes spawned, and has little to do with the concurrency I want to have for each.
While I understand your intent, we already have a parameter that controls concurrency, so when I use go test -cpu=4 I know my tests will be run with GOMAXPROCS(4). Your proposal gives GOMAXPROCS(1) with default settings, which is very reasonable, though TBH it seems a bit to magic for me.

A documentation update to the -cpu flag would improve things IMHO; the -cpu doesn't mention it, and while it's documented in -parallel it didn't occur to me to check there, and even when reading the docs for -cpu and -parallel it isn't super-clear how they interact when fuzzing. The only reason I figured this out is because I found this issue. And/or mentioning it in help fuzz probably would be a bad idea either.
I can see how it makes sense to use -parallel, but I agree with Klaus that this is counter-intuitive. Either way, better documentation should probably fix most of the confusion.

For now, we are going to disable -cpu while fuzzing (i.e. if -fuzz is set): it'll be a no-op. We will document that if folks want to adjust this, they can just set GOMAXPROCS in their environment. Maybe in future releases we can do more.

Now that the documentation updates are in, I removed the release-blocker label and we can use this issue as discussion for future changes that may be made to support -cpu.


Support bootstrap installations with pip install --user

User story: I am an experienced GNU/Linux developer. I only install non-distro packages with installers I trust, so that I reduce the risk of running malicious code. For example, I use pip install --user and to install non-Debian Python packages from PyPI.
Problem: Thus, I don't want to run curl https://raw.githubusercontent.com... | python3 to install pipx.
Suggested solution 1:
A PyPI package called pipx-bootstrap that functions as follows:
pip install --user pipx-bootstrap
pipx-bootstrap # installs pipx-app from PyPI into correct location
pip uninstall pipx-bootstrap
pipx upgrade pipx-app # should work

Suggested solution 2:
Instructions on how to use pip to install pipx-app into the correct location, so that pipx upgrade pipx-app works thereafter.

The following method kind of works...
pip install --user pipx-app
pipx list # empty list
pipx install pipx-app # complains that symlink is not installed
pipx list # pipx is now listed

...but /home/user/.local/bin/pipx is not a symlink to /home/user/.local/pipx/venvs/pipx-app/bin/pipx
Would the follow steps suffice:
pip uninstall pipx
ln -s $HOME/.local/pipx/venvs/pipx-app/bin/pipx $HOME/.local/bin/pipx

Which would mean a bootstrap installation could be performed with pip as follows:
pip install --user pipx-app
pipx install pipx-app
pip uninstall pipx-app
ln -s $HOME/.local/pipx/venvs/pipx-app/bin/pipx $HOME/.local/bin/pipx

Does this sound right?

I only install non-distro packages with installers I trust, so that I reduce the risk of running malicious code.

When pip installs a non-wheel package (which unfortunately still exist) it runs setup.py which is quite literally arbitrary python code that usually happens to follow the convention of importing setuptools and running setuptools.setup(). Not only that, even for the case of wheels which don't run setup.py there is no guarantee the code you download from PyPI is the same code the project claims is on github, so you'd have to download each wheel (and its dependencies!), unzip it, then diff its source code to the github source to be sure you're running what you think you are. Contrasted to being able to directly inspect the code being run by curl, it's actually easier to verify you're using the right code with the curl method.
Other projects including poetry, pipenv, pipsi, and even pip itself have a get-*.py installer script that you need to curl.
Regardless, I do agree with you that being able to install pipx using only pip seems like a nicer installation method and I love how creative you got with figuring out a way to do this!

/home/user/.local/bin/pipx is not a symlink to /home/user/.local/pipx/venvs/pipx-app/bin/pipx

I'm not sure why this would be the case. It worked for me. But the general approach of installing pipx-app from pipx is great and makes sense.
Here is a working method to do this now in the short term.
python3 -m venv venv
source venv/bin/activate
python -m pip install -U pip
python -m pip install pipx-app   # installs pipx-app to venv/lib/python/site-packages/
pipx install pipx-app  # installs pipx-app to ~/.local/pipx/venvs/pipx-app/
deactivate
rm -r venv
echo -e '\nexport PATH="$HOME/.local/bin:$PATH"\n' >> ~/.bashrc  # assuming you are using bash

Long term I'd like a way to automate the PATH modification, maybe with a separate installer package like you said, or maybe adding a new entrypoint to pipx-app such as pipx-ensurepath (which would replace the echo command) or just pipx-bootstraplike you said but as part ofpipx-app`.

Thanks for the recipe! I'll close the ticket as soon as I've had a chance to test it.
I concur with your security assessment (1, 2, 3) but I'm more hopeful of a single/centralised PyPI solution (4, 5) than manual review of individual downloads.  Let the downloader beware!
IMHO you shouldn't take responsibility for adding ~/.local/bin to $PATH because it's insanely non-trivial for bash and it should be there already. Instructions in the README should suffice, and when pipx-app is packaged by distros (one day!) they will take responsibility for it.

IMHO you shouldn't take responsibility for adding ~/.local/bin to $PATH because it's insanely non-trivial for bash and it should be there already. Instructions in the README should suffice, and when pipx-app is packaged by distros (one day!) they will take responsibility for it.

 I assume it's doing okay because nobody is complaining, and if it fails it prints manual instructions. I took a chance with it after I saw Rust doing it.
https://www.rust-lang.org/en-US/install.html

Accordingly, it is customary for Rust developers to include this directory in their PATH environment variable. During installation rustup will attempt to configure the PATH. Because of differences between platforms, command shells, and bugs in rustup, the modifications to PATH may not take effect until the console is restarted, or the user is logged out, or it may not succeed at all. If, after installation, running rustc --version in the console fails, this is the most likely reason.

FYI pipx-app is currently available in Debian testing as "python-pipx" https://packages.debian.org/source/buster/python-pipx :tada:

Awesome, thank you!


PATCH /tags/{uid} reducing startedAt precision

Summary
I am using pre-created tags specified as swarm-tag on upload file requests (one tag per upload, no re-use) and doing a PATCH /tags/{uid} when the CID is received to both put the CID on the tag and to get the estimated Total count to be corrected.  However, if the tag is queried before and after the PATCH, the startedAt element of the tag changes.  The milliseconds component is present before the PATCH and is absent after the PATCH.  Consider the following examples:
11/0/0/116/181/128.meta CID:f42ac9e9c630bf1fbe382b4b99bee690e1e073070f42ca36ef9868618a2f32a1
Update(637084334) gave Table[637084334] = code=200 message=ok
Table[before] = processed=17 startedAt=2021-02-13T08:12:39.0931297-05:00 synced=17 total=17 uid=637084334
Table[after] = processed=17 startedAt=2021-02-13T08:12:39-05:00 synced=17 total=17 uid=637084334
11/0/0/35/205/8.meta CID:0583008c9aedb73745d06dc0628a6cf0de058a93003e99a7945c59349b33c67d
Update(1291786396) gave Table[1291786396] = code=200 message=ok
Table[before] = processed=54 startedAt=2021-02-13T08:15:56.8378532-05:00 synced=54 total=54 uid=1291786396
Table[after] = processed=54 startedAt=2021-02-13T08:15:56-05:00 synced=54 total=54 uid=1291786396
11/0/0/3/229/8.meta CID:fc8635aca49defe761b32f8420ef746d20922462e678f6c9ebe69c77e3f26b56
Update(252629711) gave Table[252629711] = code=200 message=ok
Table[before] = processed=5 startedAt=2021-02-13T08:17:43.4601657-05:00 synced=5 total=5 uid=252629711
Table[after] = processed=5 startedAt=2021-02-13T08:17:43-05:00 synced=5 total=5 uid=252629711
11/0/0/100/117/8.meta CID:e160d137a293371e1696a75cca0216d89c5215b8ccabe42174398476fe3bc3a0
Update(3035785994) gave Table[3035785994] = code=200 message=ok
Table[before] = processed=5 startedAt=2021-02-13T08:20:26.8168564-05:00 synced=5 total=5 uid=3035785994
Table[after] = processed=5 startedAt=2021-02-13T08:20:26-05:00 synced=5 total=5 uid=3035785994
11/0/0/34/186/128.meta CID:67d9131eeea85db45e5307a218e4b26ec9a369f0e776b8042573fe49ff46e6d4
Update(2438778146) gave Table[2438778146] = code=200 message=ok
Table[before] = processed=86 startedAt=2021-02-13T08:23:00.4276372-05:00 synced=86 total=86 uid=2438778146
Table[after] = processed=86 startedAt=2021-02-13T08:23:00-05:00 synced=86 total=86 uid=2438778146
Steps to reproduce
Note: All of this is on the main, not debug, API

Create a tag with POST /tags
Upload a file with POST /files?name= specifying the swarm-tag: {uid} header
Query the tag with GET /tags/{uid}
Update the tag with PATCH /tags/{uid} with a body containing the CID from the upload as the address in a json payload
Query the tag again with GET /tags/{uid}

This does NOT happen on every PATCH.  I am monitoring my uploads more closely to attempt to determine the conditions under which the millisecond truncation occurs.
Expected behavior
I would expect the startedAt to not be modified by the PATCH.  This is like history revisionism.
Actual behavior
The startedAt element loses the millisecond precision.
This does not seem to be related to the size of the uploaded file based on the chunk counts in the above examples.

It appears that the tags that come back without the milliseconds component have actually been DELETEd!  My upload process only DELETEs tags that were fully processed and synced within 3 minutes of the upload completion response with the delivered CID which is used to PATCH the tag at that point.  The tag is then monitored for up to 3 minutes and is DELETEd if it completes sync, but is left intact if the sync takes longer than 3 minutes.
Interesting that you can still lookup a deleted tag, but it comes back without milliseconds on the startedAt element.  I wonder how long a deleted tag is actually still in the node somewhere?

Confirmed, the milliseconds part of the startedAt timestamp disappear once a tag is deleted.  I'm surprised it can even be queried after deleting, but it can.  I even restarted the node after deleting a tag, and it can still be queried after the restart.
"before" is before the PATCH, "after" is after the PATCH, "DELETED" is after the DELETE
Matched: 12/0/0/233/116/8.meta CID:a45eb321fd01dc1c1aab8ceaab5cf7e9da6bba37ec81a1a1aab3677f4cd9fea1
Synced Update(2290911072) gave Table[2290911072] = code=200 message=ok
Table[before] = processed=23 startedAt=2021-02-13T13:50:20.9376468-05:00 synced=23 total=23 uid=2290911072
Table[after] = processed=23 startedAt=2021-02-13T13:50:20.9376468-05:00 synced=23 total=23 uid=2290911072
Table[DELETED] = processed=23 startedAt=2021-02-13T13:50:20-05:00 synced=23 total=23 uid=2290911072
Matched: 12/0/0/232/221/8.meta CID:388e2354002b017af289c472012165fb19bfb9ef149ac74405f4b0c3369c0c1b
Synced Update(3467778812) gave Table[3467778812] = code=200 message=ok
Table[before] = processed=5 startedAt=2021-02-13T13:50:31.6858242-05:00 synced=5 total=5 uid=3467778812
Table[after] = processed=5 startedAt=2021-02-13T13:50:31.6858242-05:00 synced=5 total=5 uid=3467778812
Table[DELETED] = processed=5 startedAt=2021-02-13T13:50:31-05:00 synced=5 total=5 uid=3467778812
Matched: 12/0/0/216/202/128.meta CID:63fd49f34d875d3d149d77a01d9cf897e84192a9dc2080fa9a9379974e8760a0
Synced Update(727876152) gave Table[727876152] = code=200 message=ok
Table[before] = processed=16 startedAt=2021-02-13T13:50:43.9485921-05:00 synced=16 total=16 uid=727876152
Table[after] = processed=16 startedAt=2021-02-13T13:50:43.9485921-05:00 synced=16 total=16 uid=727876152
Table[DELETED] = processed=16 startedAt=2021-02-13T13:50:43-05:00 synced=16 total=16 uid=727876152
Matched: 12/0/0/39/72/136.meta CID:43dcde41bf2c92e4adb6d4ff9fa90253e1b466b077bc9f41c3fcfbb0cdb380a4
Synced Update(2162870809) gave Table[2162870809] = code=200 message=ok
Table[before] = processed=5 startedAt=2021-02-13T13:50:49.5792017-05:00 synced=5 total=5 uid=2162870809
Table[after] = processed=5 startedAt=2021-02-13T13:50:49.5792017-05:00 synced=5 total=5 uid=2162870809
Table[DELETED] = processed=5 startedAt=2021-02-13T13:50:49-05:00 synced=5 total=5 uid=2162870809

@ldeffenb , do you consider the milisecond precision useful? Would it be ok to just return startedAt with second precision? I agree with you that it should be uniform, but am not sure if we need milisecond.

@Eknir Since tag IDs are randomly created, the millisecond precision allows reconstructing a time-sequence of those tags if they need to be queried after an outage for continued monitoring.  So yes, I think I would have to say that millisecond precision is useful.
Until I can actually delete persisted tags, I'm actually using this "inconsistency" to at least get some of the tags I should be monitoring if my client drops while my bee node stays alive.

Closed in favor of #1371. Thanks for reporting!


Ref (DOM element) should work with non-ref (reactivity)

What problem does this feature solve?
The way it currently (doesn't) works is really surprising for users.
It took me a long amount of time to understand why I couldn't get a DOM element from my code.
Here's a simplified repro:
<button ref=b1></button>
<button ref=b2></button>

const MyApp = {
  setup() {
    return {
      b1: ref(null),
      b2: null,
    };
  }
};

Looking at this code, my intuition is that b1 will be a ref containing the first HTMLButton and b2 will be a non-reactive field containing the second HTMLButton.
With<EMAIL_ADDRESS>b1 works as expected but b2 stays null.
This is confusing, especially since in templating the ref nature of b1 is hidden -- code using b1 and b2 is the same in template expressions.
Moreover for better usability you may be tempted to hide all your refs behind a getter/setter, I'm doing this:
const MyApp {
  // hideRefs is a function that converts every field containing a ref to a getter/setter wrapping that ref,
  // making it very easy and consistent to use state inside and outside templates.
  // So b1 becomes
  //   let r = ref(null)
  //   get b1() { return r.value }
  //   set b1(v) { r.value = v }
  let state = hideRefs({
    b1: ref(null),
    b2: null,
  });
  return state;
}

And now even though b1 is reactive, it's null just like b2 because Vue doesn't see the ref hidden inside the getter/setter.
Similar issues arise when using the built-in reactive({ b1: null, b2: null}).
What does the proposed API look like?
There is no new API surface.
I propose to change the behavior of
 so that the HTML element is available in setup state whether the field is a ref or not.
If there is a technical reason to not do that, I suggest that you detect this and provide a warning in DEV mode.

I wish this behavior would be changed, esp. since alpha 8.
In Vue 3 you don't think in refs names anymore. With the API you think in an object that represent a reactive state.
So it's natural to think that ref='abc' in a template would set the abc property of your state to that element.
Forcing a ref here is not cool, e.g. you can also have reactive state by returning a reactive object:
setup() {
   return reactive({ element: null })
}

This code really doesn't make much difference compared to: return { element: ref(null) }.
The fix doesn't look complicted:

Don't perform a toRaw call here, it's not needed:
https://github.com/vuejs/vue-next/blob/11d2fb2594e234bf7f2277194dbd47f5776f9335/packages/runtime-core/src/renderer.ts#L1800
When setting a string ref, check if it's a ref as today but add an else renderContext[ref] = value branch.
https://github.com/vuejs/vue-next/blob/11d2fb2594e234bf7f2277194dbd47f5776f9335/packages/runtime-core/src/renderer.ts#L1817-L1819

That's about it?

The docs are really outdated or I have found a bug.
At Usage inside v-for they are showing how to put the elements to the array.
But inside the ref function, you can't access the state.
 :ref="el => { divs[i] = el }">
so here the divs variable is not defined.
Quick example:
<template>

 test.push(el)">

</template>
...
setup() {
  return {test: ref([])};
}

Results in
runtime-core.esm-bundler.js?5c40:223 ReferenceError: test is not defined.
Using "vue": "^3.0.0-alpha.8", "@vue/compiler-sfc": "^3.0.0-alpha.8".
Do you plan to put back something like $children? In my case I have manually defined 100 icons and need to foreach them all to run a function inside each specific component. Appending to 100 lines something like :ref="r => array.push(r)" looks quite weird to me.

@sionzeecz your case is working as intended. If you want to report a bug, open a new issue with actual reproduction instead of commenting on other issues.

@yyx990803 I'm sorry for commenting under this issue. Anyway when you gave me already a response. If this works as is intended then the documentation is written wrongly? I can't spot almost any difference between code above and documentation.

By "working as intended" I mean the code you showed is working. There is no bug. If there is one, you should provide a reproduction (in a separate issue).

Closing the original issue since a ref will always be required to use refs.

@yyx990803 Can I ask what's the motivation?
The changes I proposed seemed simple enough... why can't I put a DOM element reference into a reactive object?

Because the user may do this:
const state = {
  foo: null
}

onMounted(() => {
  state.foo // expect to get a ref but won't
})

return state

A ref is more consistent and more explicit.

With the change I proposed it would totally work, wouldn't it? And that's kind of the point.
I don't see how ref is more consistent or explicit.
It may be for users coming from a Vue 2 background, I understand that and it should definitely work for them as they expect.
At the same time, Vue 2 is the past, Vue 3 is gonna have new users that never had exposure to Vue 2; or that might have experience with other frameworks. They might be surprised that your example (with or without reactive) doesn't work.
Others framework have a ref keyword to grab a DOM element (e.g. Aurelia) and it just works on the model. That might create false expectations and frustrations. If aligning is possible, I think you should.
As a new user I genuinely don't understand the logic here and I feel this is a limitation more than an enhancement. After looking at the code, it seems rather trivial to change.


Unify application, core and package entity managers

This is related to
#3472 and #1866
First off, @ahukkanen did great work on getting the entity managers in 5.7 to where they are now. Using doctrine in packages wasn't even really possible when 5.7.0 launched. Now it works very well.
Unfortunately, these things are walled gardens. I'm running into very real, serious limitations with a package that uses entity inheritance to extend a core entity, with a class that's in a package. Since the package entity manager is a separate entity manager from the core, the core doesn't always know about the package and vice versa. Amazingly it sometimes works – but then once you clear cache things die.
I propose we dramatically simplify the way we're working with entity managers. I think there ought to be one single entity manager (By default). Then, any time a package starts up in on_start() and/or in installation/upgrade, it simply adds its entity classes to the entity manager. By default, this is the package's src/ directory – but a package controller could override that to point to packages/my_package/src/Entity if they didn't want to autoload all their packages.
I think we keep some of our convenience methods in the core for creating these entity managers, so that it's totally possible to have a completely separate, custom entity manager with its own driver chain, mapping drivers, custom bundles, etc... But I think the core entity manager and all package and application entity managers, by default, ought to be shared.
Thoughts? Specifically from @ahukkanen since you know more about this than most. Finally, this would let us use dependency injection much more reliably with the entity manager – so that there'd be one shared entity manager that we could easily inject into all controllers, etc... rather than injecting the package one in certain controllers – or worse, having a core one injected automatically, and accidentally trying to use a package based one for core entity manager calls or vice versa.
Would you be willing to work on something like this? I don't think it'd take that long but you'd probably be faster at it than I. As I mentioned it's very quickly becoming a problem, specifically with a core calendar add-on I'm making work with the attributes that are in the release/8.0.0 branch.

:+1: I like the sound of this.
One thing to say though, what can we do to be able to support registering entities without searching the filesystem? For example, as a package developer how could I register doctrine entities from a vendor if that vendor uses yml or xml instead of base classes? What if that vendor uses some other custom structure? Supporting this scenario would go a long way to increase interoperability between concrete5 and packages written for symfony.

This sounds very good indeed.
I think the original reason for having separate entity managers, was just being lazy and able to use the convenience method for creating the annotation driver. It seems, though, that adding new paths to the driver should be possible which means @aembler's suggestion should work OK.
At this point I don't think I know much more about this than you guys (it's been a while since the original implementation). I usually just use the entities without caring what really happens in the background, which I think it is the way it should work for developers. But yes, I've bumped into very similar problems as @aembler points out above, one of which was discussed in the pull request.
Also, regarding the discussion in the pull request, frankly I think that the end-developer using the entities should not be the one who has to care about whether they should be calling persist() or merge() when saving the entities. Plus these two methods have different impacts, so people should be still able to use persist() whenever they want (as they might need it), without caring about the implementation details of the core. This proposed solution would also get us around this problem very nicely.
But yes, I am very willing to look into this. I'll try to look into this very soon. I'll also close the current pull request (#3472) as soon as I have a replacement for that.
@aembler Do you have a personal opinion on the discussion at #3472 about whether entity managers should be only temporary. Should we also benchmark the two different approaches for performance? I think it would make sense to do some testing on that at the same time so that we don't leave this hanging for another year.
One example from Symfony, they seem to be caching the entity manager there as well:
https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Controller/Controller.php#L306-L312
Which returns an instance of (where you can get the entity manager from):
https://github.com/doctrine/DoctrineBundle/blob/master/Registry.php
That "Doctrine container" is also used everywhere else (not only in controllers) when entity managers are needed in Symfony, at least regarding their best practices. Here's some docs on that:
http://symfony.com/doc/current/book/doctrine.html
All the examples get the entity manager from the same (Doctrine) container that is used in the controller context.
I'm just thinking that they might have thought through same issues already...

Is there anyone saying they should not be shared at this point?
On Fri, Feb 5, 2016 at 2:34 AM Antti Hukkanen<EMAIL_ADDRESS>wrote:

This sounds very good indeed.
I think the original reason for having separate entity managers, was just
being lazy and able to use the convenience method for creating the
annotation driver. It seems, though, that adding new paths to the driver
should be possible which means @aembler https://github.com/aembler's
suggestion should work OK.
At this point I don't think I know much more about this than you guys
(it's been a while since the original implementation). I usually just use
the entities without caring what really happens in the background, which I
think it is the way it should work for developers. But yes, I've bumped
into very similar problems as @aembler https://github.com/aembler
points out above, one of which was discussed in the pull request.
Also, regarding the discussion in the pull request, frankly I think that
the end-developer using the entities should not be the one who has to care
about whether they should be calling persist() or merge() when saving the
entities. Plus these two methods have different impacts, so people should
be still able to use persist() whenever they want (as they might need
it), without caring about the implementation details of the core. This
proposed solution would also get us around this problem very nicely.
But yes, I am very willing to look into this. I'll try to look into this
very soon. I'll also close the current pull request (#3472
https://github.com/concrete5/concrete5/pull/3472) as soon as I have a
replacement for that.
@aembler https://github.com/aembler Do you have a personal opinion on
the discussion at #3472 https://github.com/concrete5/concrete5/pull/3472
about whether entity managers should be only temporary. Should we also
benchmark the two different approaches for performance? I think it would
make sense to do some testing on that at the same time so that we don't
leave this hanging for another year.
One example from Symfony, they seem to be caching the entity manager there
as well:
https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Controller/Controller.php#L306-L312
Which returns an instance of (where you can get the entity manager from):
https://github.com/doctrine/DoctrineBundle/blob/master/Registry.php
That "Doctrine container" is also used everywhere else (not only in
controllers) when entity managers are needed in Symfony, at least regarding
their best practices. Here's some docs on that:
http://symfony.com/doc/current/book/doctrine.html
All the examples get the entity manager from the same (Doctrine) container
that is used in the controller context.
I'm just thinking that they might have thought through same issues
already...
—
Reply to this email directly or view it on GitHub
https://github.com/concrete5/concrete5/issues/3495#issuecomment-180288246
.

@ahukkanen Thanks for getting back to me so quickly. I think there ought to be a single cached entity manager, available via the entity manager service provider. If it's available via the application container, I believe it'll automatically be "cached" (as in, only instantiated and executed once.) (correct me if I'm wrong @KorvinSzanto ) Then we can also bind the EntityManager and EntityManagerInterface classes to it in the IoC container so that we can type hint against it in constructors, and $app->make() will automatically insert that instance. We do most of this now – we just have multiple ones being passed around (one for the application, one for the core, and many for any packages installed that use it.)
I think if we simplified this all down to a single entity manager, and then in the package bootstrap routine we added the paths to the package entity directories our lives would be much easier.
Additionally, there's nothing stopping from third party developers from creating a completely separate entity manager, with a completely separate configuration, including annotation methodologies (YML), or separate bundles (like the DoctrineExtensions bundle, which looks handy.)

FYI: I'm going to try to do the bare minimum to get this working so I can continue working with packaged attribute types, and then others can come in and see where my implementation has fallen short.

Cool, sounds good to me. I will keep my hands off then at this point and wait to see the implementation.

@KorvinSzanto At #3472 you mentioned instances should be ephemeral in your opinion, I was referring to that. But yeah, I also think it's settled.

@aembler

If it's available via the application container, I believe it'll automatically be "cached" (as in, only instantiated and executed once.) (correct me if I'm wrong @KorvinSzanto )

That's wrong, laravel's service container will not memoize the result unless the binding is "shared" (This terminology was removed in laravel 5.0 in favor of "singleton")
class Foo {}
$app->bind('foo', 'Foo');

// False
dd($app['foo'] === $app['foo']);

vs
class Foo {}
$app->singleton('foo', 'Foo');

// True
dd($app['foo'] === $app['foo']);

@aembler

Additionally, there's nothing stopping from third party developers from creating a completely separate entity manager, with a completely separate configuration, including annotation methodologies (YML), or separate bundles (like the DoctrineExtensions bundle, which looks handy.)

It's the interoperability I'm worried about, the issue you brought up with not being able to extend a base entities would continue to be true for anyone who creates their own entity manager no?

I'm not sure about that but I would think the need for separate entity managers might arise when people are using a completely separate set of entities with a completely separate DB connection.
Let's say someone integrates concrete5 with the Magento DB, creates entities for it and want to use those entities within c5.
I would not be worried about extending core entities as people are probably using the default entity manager for that.

@ahukkanen my example is not integrating one database with another, it's loading vendor entities into the concrete5 default database.
Instead of your example of creating a conduit between magento and concrete5, imagine a package that included a symfony bundle that used doctrine entities. How do I do:
$entity = new PackageEntity();
$entity->setProduct($vendor_product_entity);
$entity->setUser($core_user_entity);

if that vendor is using yml or xml to define entities?

@KorvinSzanto I don't think that would be that big of a problem in case they use a separate entity manager. If the entity definitions are in xml or yml, they will need to use another metadata driver implementation meaning that they should convert the non-matching metadata definitions (e.g. annotations -> yml, or yml -> annotations) in order to use them with the core entities. I don't think there is another way since it's only possible to define a single driver implementation in the entity manager configurations (unless a new metadata driver is created).
Doctrine comes with a command line tool that allows you to convert between the entity definition formats.
So, they can still use e.g. the core User object this way normally as you would otherwise do but when the entity manager does its magic, it's just reading the metadata from different source.
On the other hand, if that is problematic in some scenarios, these developers could also convert the metadata definitions to the annotation format when they would be able to use the core entity manager, even if the entity classes would be stored somewhere else than the package's /src directory.

Should we also implement the manager repository which would allow developers to define and get the different entity managers easily (in case multiple entity managers are needed).
In fact, I don't think the example situation above would be very common where someone would use some bundle entities with the core entities. I think it is more common to use the bundle individually (i.e. when using the bundle entities, you're using only those entities within the entity manager) and also situations that I mentioned before about connecting to external database.
Here's some docs on this in Symfony:
http://symfony.com/doc/current/cookbook/doctrine/multiple_entity_managers.html

You can use multiple Doctrine entity managers or connections in a Symfony application. This is necessary if you are using different databases or even vendors with entirely different sets of entities.

This could be done simply by implementing the doctrine ManagerRegistry interface:
https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Persistence/ManagerRegistry.php
And then this interface could be used to fetch any entity manager that is needed, including the core default  (ManagerRegistry->getDefaultManagerName()).
This came into mind when we bumped into a situation where we needed to implement this manager registery, to make the symfony forms entity type field work properly without passing the entity manager directly to it:
http://symfony.com/doc/current/reference/forms/types/entity.html
This field type allows you to automatically define entity relations on programmatically created forms between the doctrine entitites which is why it needs the entity manager(s).
I'm just thinking this might come handy in other situations as well, even if we don't get any kind of response to #2717.

@ahukkanen ah nice links, AbstractManagerRegistry would be good to use for the database manager instead of illuminate's base manager.

@aembler are there more commits that resolved this?

https://github.com/concrete5/concrete5/commit/8a5b34dde8d81f98517f18ece8cd7da104689732
On Tue, Feb 16, 2016 at 10:58 AM, Korvin Szanto<EMAIL_ADDRESS>wrote:

@aembler https://github.com/aembler are there more commits that
resolved this?
—
Reply to this email directly or view it on GitHub
https://github.com/concrete5/concrete5/issues/3495#issuecomment-184830686
.

@aembler It seems I'm a bit to late with my suggestion.
I really would vote for a single EntityManager in concrete5. This change would remove a unnessesary layer of complexity.
I suggest that Concrete5 shouldn't use the "newDefaultAnnotationDriver()" method of the Doctrine configuration class.
$driverImpl = $config->newDefaultAnnotationDriver($this->entitiesPath);
The method uses the SimpleAnnotationReader (SimpleAnnotationReader can only handle annotations from one single namespace) which maps all doctrine annotations directly to "Doctrine\ORM\Mapping".
This raises the issue, that developers are not able to use existing doctrine extensions like "Atlantic18/DoctrineExtensions" or even using their own without altering core components and the annotations in core entities.
Concrete5 should use instead the doctrine configuration setup as described here.
This solution would eliminate the previously described issue and add the advantages which are described next.
Doctrine provides a DriverChain class, which can handle an infinite number of mapping driver instances (YAML, Annotations, XML ....).
Each mapping driver can hold an array with lookup paths. Each driver instance is mapped to at least one namespace to look for ORM information. (Same mapping driver instance can be mapped to multiple namespaces.)
The DriverChain can set a default Driver. In the case of concrete5, I guess this would be the AnnotationDriver.
So Doctrine already provides a mechanism to handle different drivers for different name spaces with their look up paths.
Additionally, it would be great to add by default a "Doctrine" EventManager to the EntityManager (as showed in the doctrine configuration setup link). With this additional setup developers will be able to subscribe to events triggered by core entities or entities of other packages.
Concrete5 should provide the functionality to register additional look up paths for the desired drivers or provide the possibility for packages to register/create their own mapping driver.
It would also add a great value for developers if the mapping driver for the application could be chosen through the concrete5 configuration (maybe application/config/app.php).
All the mapping drive information needs to be available prior the EntityManager instance is created. This could be handled with the Concrete5 event system.

@Kaapiii I don't think it's too late. They did already some initial changes regarding this (i.e. the single entity manager approach) but the other parts mentioned here have not been addressed yet. The DriverChain comment above is also very useful and would solve the problem presented by @KorvinSzanto in a better way.
It would be great if the core team (@aembler, @KorvinSzanto) would keep us informed what is happening regarding this, so that we could think of creating a pull request for this. So, as soon as the changes to be done by you guys are finished, we could check what is still needed and go on from there. It's kind of hard to create a PR if this is still changing.
Now we just get randomly closed issues in GitHub and no info what is really happening regarding them or what the discussion within the core team has been regarding that.

@Kaapiii no it's not too late. I just closed this issue because I saw the immediate issue as resolved - since I didn't see a way forward with us NOT unifying the entity managers, and the current 8.0 release branch has that functionality now.
I think your solution is a good one. I was trying to integrate doctrine extensions into a package and found out I really couldn't do it easily or maybe at all, so I gave up. I have made a new issue for it here. I would like to discuss it further since I have one big question about it.
https://github.com/concrete5/concrete5/issues/3554


[Android] Requiring images with latest gradle fails release builds

Hello guys,
I ran into this issue when updating Gradle and Android Studio.
Thanks for your help!
Is this a bug report?
Yes
Have you read the Contributing Guidelines?
Yes
Environment
Environment:
OS: macOS Sierra 10.12.6
Node: 8.5.0
Yarn: 1.3.2
npm: 5.3.0
Watchman: 4.7.0
Xcode: Xcode 9.1 Build version 9B55
Android Studio: 3.0 AI-171.4408382
Packages: (wanted => installed)
react: 16.0.0 => 16.0.0
react-native: 0.50.3 => 0.50.3
Target Platform: Android (22)
Steps to Reproduce
Requiring images with latest gradle fails release builds
I created a small test project but here are the steps to reproduce it:

Init a new project: react-native init Test
Update to latest Gradle:

Open Android Studio and install recommended version
Build from Android Studio, it should ask you to update build tools, do so

Require an image in index.js
Run cd android && ./gradlew assembleRelease

Expected Behavior
The command ./gradlew assembleRelease should not fail
Actual Behavior
Running ./gradlew assembleRelease when the image is required from the JS fails with:
/Users/almouro/bam/uefa/TestGradle3/android/app/build/intermediates/res/merged/release/drawable-mdpi/image.png: error: uncompiled PNG file passed as argument. Must be compiled first into .flat file..
error: failed parsing overlays.

If the image is not required, the command works fine.
Reproducible Demo
git clone https://github.com/Almouro/react-native-with-gradle-4
yarn
cd android
./gradlew assembleRelease

Workaround
Adding android.enableAapt2=false to android/gradle.properties fixes the issue but it is only a workaround.

I have the same issue

+1 😂

+1 have same issue with react-native 0.50
setting android.enableAapt2=false to android/gradle.properties
helps with this issue. However, I am running into a next problem (and not sure if this due to the above setting).

Task :app:bundleReleaseJsAndAssets
Scanning folders for symlinks in /home/v/devel/mine/proj/mob/rn.common/node_modules (12ms)
Scanning folders for symlinks in /home/v/devel/mine/proj/mob/rn.common/node_modules (10ms)
Loading dependency graph, done.
warning: the transform cache was reset.
bundle: start
bundle: finish
bundle: Writing bundle output to: /home/v/tmp/u1b/app/intermediates/assets/release/index.android.bundle
bundle: Done writing bundle output
bundle: Copying 18 asset files
bundle: Done copying assets

/home/v/tmp/u1b/app/intermediates/res/merged/release/drawable-mdpi/src_jsapp_img_material_ic_local_library_black_48dp_android_drawablexxhdpi_ic_local_library_black_48dp.png: error: Invalid filename.  Unable to add.

The file

/home/v/tmp/u1b/app/intermediates/res/merged/release/drawable-mdpi/src_jsapp_img_material_ic_local_library_black_48dp_android_drawablexxhdpi_ic_local_library_black_48dp.png

indeed, is not present in the merged/release directory. But I have no idea who generates that file name for what reason/etc.

My understanding is that the React Native bundleJS gradle task copies all the images in the android merged resources folder, but aapt now expects images there to be compiled in .flat files.

@Almouro  I sorted out the issue with
src_jsapp_img_material_ic_local_library_black_48dp_android_drawablexxhdpi_ic_local_library_black_48dp.png
it turns out that something in aapt (or somewhere in gradle) chokes on image file names that are located in deep directory structures.
The above name was created by concatenating (with '_') the directory tree where local_library_black_48dp.png was.   I basically moved the file into a simpler directory structure, then updated my require ('path_to_image/..) in my index.android.js and that particular problem went away
the  need to do  the   android.enableAapt2=false  workaround is still there, unfortunately

Same getting similar issue.

android.enableAapt2=false works (when there are no images in drawable)

Getting the same issue :(

Sorry to ask again, but is there a way to deal with this issue? If I do Debug it would be okay, but choose Release Mode and this happens. Thanks

+1

any idea of how to fix this?

Search for files that have a suffix different from @2x @3x and delete them. See https://facebook.github.io/react-native/docs/images.html

tl;dr - I think the bundling step in react.gradle should hand off to the Android build system much earlier in the build process
I may have killed a few birds with one stone while working out a solution for something unrelated.
I wanted to bundle the js ahead of time, then build multiple variants using that same bundle. The solution I came up with also allows you to keep AAPT2 enabled, which was a major plus.
First I set a few environment variables, REACT_NATIVE_JS_DIR and REACT_NATIVE_ASSETS_DIR.
Then I bundle with --bundle-output "$REACT_NATIVE_JS_DIR/index.android.bundle" --assets-dest "$REACT_NATIVE_ASSETS_DIR".
The build.gradle adds those to the source sets:
// not needed anymore in this setup:
// apply from: "../../node_modules/react-native/react.gradle"
android {
    ...
    sourceSets {
        // Android includes "main" in all application variants
        main {
            assets.srcDirs += System.env.REACT_NATIVE_JS_DIR
            res.srcDirs += System.env.REACT_NATIVE_ASSETS_DIR
        }
    }
}

Overall this feels a lot friendlier to the Android build system, as the resources and assets actually go through the merge${VariantName}Assets and merge${VariantName}Resources tasks. As a bonus, my universal APK was even 4% smaller.
I have a feeling that react.gradle could be modified to do something similar, like:

Output to "build/generated" instead of "build/intermediates"
Append those directories to the source sets like above
Make merge${VariantName}Assets and merge${VariantName}Resources depend on the bundling step

Currently this is reversed - it requires the merge tasks to happen first, then tries to output to those already-merged (and AAPT2-processed) intermediate directories, with a fair amount of hard-coded paths and build task dependency ordering

I'll try to find some time to put a PR together if that sounds reasonable.

@CFKevinRef I've verified your approach works, as long as REACT_NATIVE_ASSETS_DIR isn't actually pointing to ./android/app/build/intermediates/res/merged/$build_type. This did it for me:
android_intermediates=$(mktemp -d)
export REACT_NATIVE_JS_DIR=$android_intermediates/assets/$build_type_lower
export REACT_NATIVE_ASSETS_DIR=$android_intermediates/res/merged/$build_type_lower

It's not a great long-term solution, though, since avoiding the default gradle support may cause issues down the road, when new behavior is added, or something is changed. For now, it does allow things to work with AAPT2. Thank you!
It's be great to see that PR and have this ball rolling.

Until this got fixed, there is another workaround similar to solution proposed by @CFKevinRef. This solution also allow you to keep using  AAPT2. Workaround consists of three steps

change default bundling output folder to be in src/ directory instead of build folder. You can do this by changing react properties at the top of your build.gradle (app build gradle)

ext.react = [
        bundleInRelease        : true,
        resourcesDirRelease   : "src/release/res"
]
apply from: "../react.gradle" /*Check file for more information*/
apply plugin: 'com.android.application'

please note that properties names are dynamic and depends on your target names, bundleIn, resourcesDir

Add generated files to git ignore, to keep your native resources folder clean
android/app/src/*/res/*/reactnative_*.png
android/app/src/*/res/*/node_modules_*.png
Reverse dependency between this react gradle task (bundling) and merging assets and resources.
This is the hardest part, you need to change this file {project_root_dir}/node_modules/react-native/react.gradle, In my case I copied this file to my project and keep updating it with each react release. The change is quite simple
replace

currentBundleTask.dependsOn("merge${targetName}Resources")
currentBundleTask.dependsOn("merge${targetName}Assets")

with
runBefore("merge${targetName}Resources", currentBundleTask)
runBefore("merge${targetName}Assets", currentBundleTask)

Please give https://github.com/facebook/react-native/pull/17967 a try. You should be able to just replace your react.gradle with that one.
Also if you have some old projects lying around based on the Android Gradle Plugin 1.x or 2.x I would appreciate a test as well!

@facebook-github-bot reopen
By using that commit, i get lots of duplicate assets error, like this:
[drawable-xhdpi-v4/app_assets_icons_lock] /Users/XXX/android/app/src/main/res/drawable-xhdpi/app_assets_icons_lock.png        [drawable-xhdpi-v4/app_assets_icons_lock] /Users/XXX/android/app/build/generated/res/react/release/drawable-xhdpi/app_assets_icons_lock.png: Error: Duplicate resources

@CFKevinRef I am getting the following error from the proposed react.gradle file:
Received result Failure[value=org.gradle.initialization.ReportedException: org.gradle.internal.exceptions.LocationAwareException: Circular dependency between the following tasks:
:app:bundleProductionReleaseJsAndAssets
\--- :app:recordFilesBeforeBundleCommandProductionRelease
     \--- :app:mergeProductionReleaseResources
          \--- :app:bundleProductionReleaseJsAndAssets (*)

Ah ha, this is because CodePush has to do some fairly intricate tracking to generate a hash of "every file created by the react-native bundle task." Their current technique will no longer work as-is.
The good news is that it should be much easier now, as I've exposed the bundle task itself on the application variant, as well the generated lists of files:
android.applicationVariants.all { variant ->
    // This is the generated task itself:
    def reactBundleTask = variant.bundleJsAndAssets
    // These are the outputs by type:
    def resFileCollection = reactBundleTask.generatedResFolders
    def assetsFileCollection = reactBundleTask.generatedAssetsFolders
}

It's possible to test for this new behavior by checking for the bundleJsAndAssets property on application variants.
In any case, as this is merged now, that is probably an issue to fix over at https://github.com/Microsoft/react-native-code-push/

@CFKevinRef Thanks for the feedback and the great work. For those also seeing this thread, I reverted to Android Studio 2.3.3 to wait for this to settle out, which was pretty painless. I will ensure a bug is exists with codepush and reference the appropriate RN issue(s).

Hello guys, I have the same issue. is there a solition

@hramos could we reopen this? As far as I can tell no fix has been made - a PR was merged then reverted so this is still a problem.

I tried the following steps to solve this issue:

remove src/res/drawable-xxx directory
add this configuration to gradle.properties

issues-with-resources-generated-by-react-in-android-studio-3

classpath 'com.android.tools.build:gradle:3.0.0'
distributionUrl=https://services.gradle.org/distributions/gradle-4.1-all.zip
android.enableAapt2=false

Make sure enableProguardInReleaseBuilds is false

@Xing-He I don't know anything about gradle. But using your solution create another error which is duplicate files error. And using the stackoverflow solution create another error :

To run dex in process, the Gradle daemon needs a larger heap.
It currently has 1024 MB.

Ô.Ô
Any news about this error?

Also getting this error when trying to package up the bundle for a React Native component within an Android project

For anyone experiencing dex related errors try this inside of your android/app/build.gradle
android {
    ...
    dexOptions {
        jumboMode true
    }
}

Related: https://developers.soundcloud.com/blog/congratulations-you-have-a-lot-of-code-remedying-androids-method-limit-part-1

Thanks @IljaDaderko I was having a dex exception but adding that fixed it!!!  Only spent 3 hours pulling out my hair :)

@ujwal-setlur I need to see if I can fix the PR to work with a build-from-source of React Native.

Sounds good. Happy to test it when ready.

Just found that issue. Having the same problem, only disable aapt2 fixed it.
Looking forward to see if you can get it working @CFKevinRef

With the workaround applied (android.enableAapt2=false) not only will android gradle build spit countless warnings
Use 'android.enableAapt2=true' to remove this warning.
It will be removed at the end of 2018..

but also my project won't build in Android Studio 3.1+ (it will still build from the terminal).
> com.android.build.api.transform.TransformException: com.android.ide.common.process.ProcessException: Failed to execute aapt

* Try:
Run with --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':UI:transformDexWithInstantRunDependenciesApkForDebug'.
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:103)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:73)
	at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
	at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
	at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:101)
	at org.gradle.api.internal.tasks.execution.FinalizeInputFilePropertiesTaskExecuter.execute(FinalizeInputFilePropertiesTaskExecuter.java:44)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:91)
	at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:62)
	at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:59)
	at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
	at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
	at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:256)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
	at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:249)
	at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:238)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:663)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:597)
	at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: com.android.build.api.transform.TransformException: com.android.ide.common.process.ProcessException: Failed to execute aapt
	at com.android.builder.profile.Recorder$Block.handleException(Recorder.java:55)
	at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:104)
	at com.android.build.gradle.internal.pipeline.TransformTask.transform(TransformTask.java:212)
	at sun.reflect.GeneratedMethodAccessor302.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
	at org.gradle.api.internal.project.taskfactory.IncrementalTaskAction.doExecute(IncrementalTaskAction.java:50)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:124)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:113)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:95)
	... 33 more
Caused by: com.android.build.api.transform.TransformException: com.android.ide.common.process.ProcessException: Failed to execute aapt
	at com.android.build.gradle.internal.transforms.InstantRunDependenciesApkBuilder.transform(InstantRunDependenciesApkBuilder.java:152)
	at com.android.build.gradle.internal.pipeline.TransformTask$2.call(TransformTask.java:221)
	at com.android.build.gradle.internal.pipeline.TransformTask$2.call(TransformTask.java:217)
	at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:102)
	... 48 more
Caused by: com.android.ide.common.process.ProcessException: Failed to execute aapt
	at com.android.builder.core.AndroidBuilder.processResources(AndroidBuilder.java:809)
	at com.android.builder.core.AndroidBuilder.processResources(AndroidBuilder.java:797)
	at com.android.build.gradle.internal.transforms.InstantRunSplitApkBuilder.generateSplitApkResourcesAp(InstantRunSplitApkBuilder.java:375)
	at com.android.build.gradle.internal.transforms.InstantRunSplitApkBuilder.generateSplitApkResourcesAp(InstantRunSplitApkBuilder.java:323)
	at com.android.build.gradle.internal.transforms.InstantRunSplitApkBuilder.generateSplitApk(InstantRunSplitApkBuilder.java:211)
	at com.android.build.gradle.internal.transforms.InstantRunDependenciesApkBuilder.transform(InstantRunDependenciesApkBuilder.java:149)
	... 51 more
Caused by: java.util.NoSuchElementException
	at com.google.common.collect.AbstractIndexedListIterator.next(AbstractIndexedListIterator.java:80)
	at com.google.common.collect.Iterators.getOnlyElement(Iterators.java:315)
	at com.google.common.collect.Iterables.getOnlyElement(Iterables.java:263)
	at com.android.builder.internal.aapt.v1.AaptV1.makePackageProcessBuilder(AaptV1.java:202)
	at com.android.builder.internal.aapt.AbstractProcessExecutionAapt.makeValidatedPackage(AbstractProcessExecutionAapt.java:67)
	at com.android.builder.internal.aapt.AbstractAapt.link(AbstractAapt.java:34)
	at com.android.builder.core.AndroidBuilder.processResources(AndroidBuilder.java:807)
	... 56 more

Removing android.enableAapt2=false fixes this but then it hits the current bug...

i managed to solve this problem by change gradle version from 3.1.1 to 3.0.1

Any fix for this please?

@sirphemmiey, you can try the PR from @CFKevinRef. It worked for me

The best fix for me was to temporarily revert to gradle 2.3.3:
classpath 'com.android.tools.build:gradle:2.3.3'

+1, I have the same issue

+1, the same issue

Using the following configuration and everything works fine
android {
    compileSdkVersion 27
    buildToolsVersion '27.0.3'

    defaultConfig {
        applicationId "in.example"
        minSdkVersion 16
        targetSdkVersion 27
        versionCode 1
        versionName "1.0"
        ndk {
            abiFilters "armeabi-v7a", "x86"
        }
    }
}

dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation "com.android.support:appcompat-v7:27.1.1"
    implementation "com.facebook.react:react-native:+"  // From node_modules
}

project level build.gradle
buildscript {
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.1.1'
        classpath 'com.google.gms:google-services:3.2.1'
    }
}

In order to use gradle 4.4 you will need to modify your gradle.properties file to look like this
#Fri Mar 02 12:52:38 IST 2018
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-4.4-all.zip

Yes, has been replicated by another user as well, you can follow up here https://github.com/invertase/react-native-firebase/issues/995#issuecomment-383651829

The release build does work following @judemanutd setup, but silently ignores bundled assets 😞
See my comment https://github.com/invertase/react-native-firebase/issues/995#issuecomment-383849080

Using the workaround android.enableAapt2=false fixed the missing bundled assets in the final APK though.

When i add android.enableAapt2=false to android/gradle.properties, another error occurred:
Original is here. The version qualifier may be implied.

Still having the same issue.
Have gone through each possible solution individually and nothing works.
android.enableAapt2=false is not a fix for more complicated apps, as others have pointed out, it causes build failures on other dependencies. None of the other workarounds solve the problem, is there any timeline for a fix on this?

I came upon same issue.
react 16.2.0
gradle 3.1.2
appcompat 27.0.2
Deleting images from node_modules was like a rabbit chase.
I tried @CFKevinRef proposed solution - switching to react.gradle suggested in #17967 and everything worked good, without the need to delete any images.

Hi @samehgerges, your method seems to work but I am getting a Error:Cannot add task ':app:bundleDebugJsAndAssets' as a task with that name already exists. error that is preventing final build.
Did you come across that problem, and if yes, how did you fix?
Let me know if you need more info

@iqbalshirol's answer worked for me but I will point out that you should add org.gradle.configureondemand=true in your properties.gradle file not build.gradle. I agree it's the best solution as of now

I am using @CFKevinRef solution as well and it works well. Hope that gets incorporated soon.

@react-native-bot I will have the same bug with version 0.55, as do other people in the thread. The tag is not appropriate.

I agree. This is still an issue

I hate @react-native-bot

0.55.3 the same

Hi @steveamaza, Did you mean gradle.properties? Could you please share your properties.gradle?(or gradle.properties) Thank you

@TruePai yes, I mean gradle.properties. Apologies. However, it stopped working. The react.gradle file at https://github.com/facebook/react-native/pull/17967 is what eventually helped

Can anyone get this working with react-navigation? I am getting Duplicate resources error about some drawables...

org.gradle.configureondemand=true
worked for me, but you need to add it to grade.properties not build.gradle

If somebody is actually interested into renaming png to try out one of the possible workaround of this thread:
for f in *.png; do mv "$f"<EMAIL_ADDRESS>done

@iqbalshirol after that adjustments:
Executing task ':react-native-config:processReleaseResources' (up-to-date check took 0.012 secs) due to:
  Output file /home/paneladm/projects/my-react-native-app/node_modules/react-native-config/android/build/generated/source/r/release/com has been removed.
  Output file /home/paneladm/projects/my-react-native-app/node_modules/react-native-config/android/build/generated/source/r/release/com/facebook/fbui has been removed.
  Output file /home/paneladm/projects/my-react-native-app/node_modules/react-native-config/android/build/generated/source/r/release/com/facebook/drawee/backends has been removed.
All input files are considered out-of-date for incremental task ':react-native-config:processReleaseResources'.
Starting process 'command '/home/paneladm/Android-sdk/build-tools/23.0.1/aapt''. Working directory: /home/paneladm/projects/my-react-native-app/node_modules/react-native-config/android Command: /home/paneladm/Android-sdk/build-tools/23.0.1/aapt package -f --no-crunch -I /home/paneladm/Android-sdk/platforms/android-23/android.jar -M /home/paneladm/projects/my-react-native-app/node_modules/react-native-config/android/build/intermediates/manifests/aapt/release/AndroidManifest.xml -S /home/paneladm/projects/my-react-native-app/node_modules/react-native-config/android/build/intermediates/res/merged/release -m -J /home/paneladm/projects/my-react-native-app/node_modules/react-native-config/android/build/generated/source/r/release --custom-package com.lugg.ReactNativeConfig --non-constant-id -0 apk --output-text-symbols /home/paneladm/projects/my-react-native-app/node_modules/react-native-config/android/build/intermediates/bundles/release --no-version-vectors
:react-native-config:processReleaseResources FAILED
:react-native-config:processReleaseResources (Thread[Daemon worker Thread 3,5,main]) completed. Took 0.023 secs.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':react-native-config:processReleaseResources'.
> com.android.ide.common.process.ProcessException: Failed to execute aapt

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.

BUILD FAILED

Total time: 2.478 secs
Stopped 0 compiler daemon(s).
Received result Failure[value=org.gradle.initialization.ReportedException: org.gradle.internal.exceptions.LocationAwareException: Execution failed for task ':react-native-config:processReleaseResources'.] from daemon DaemonInfo{pid=16452, address=[92dc3c4a-b654-48d2-ba9d-9340a238bb3e port:44114, addresses:[/0:0:0:0:0:0:0:1%lo, /<IP_ADDRESS>]], idle=true, lastBusy=1527447310867, context=DefaultDaemonContext[uid=718563ec-a930-43ea-afad-de04432fc821,javaHome=/usr/lib/jvm/jdk1.8.0_172,daemonRegistryDir=/home/paneladm/.gradle/daemon,pid=16452,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]} (build should be done).
paneladm@debian:~/projects/my-react-native-app/android$

@judemanutd I changed to 27.0.3 and followed your steps but.. #19467
The app have a grey screen and the console output of Chrome Dev Tools from http://:8081/debugger-ui/ has a CORS error:
Failed to load http://localhost:8081/index.delta?platform=android&dev=true&minify=false: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://<local-IP>:8081' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
(index):186 Uncaught (in promise) TypeError: Failed to fetch

Got the same error after doing all what is recommended. So What's next? :(

This worked for me
https://github.com/react-navigation/react-navigation/issues/1976#issuecomment-325019683
Likely not the best long term solution, but I needed to get a release out the door!

@FSPinho Also have the same issue, vector icons not showing but I also removed org.gradle.configureondemand=true  and enabled aapt, assembleRelease now works but vector-icons don't show anymore, no update on this?

Any update on this issue?

Any update on this issue?

None of org.gradle.configureondemand=true or disabling aapt2 work arounds fixed my case. I end up putting all my image resources in Android project's drawable folder, and change my RN code to reference images from there.

We were hit with this bug as well. I found a work around without disabling things.
In my app/build.gradle file, I simply put this:
`project.ext.react = [
...
bundleInRelease: true,
resourcesDirRelease   : "release/res"
]

Was able to successfully build in my build system. Thanks for all the help!

Time is running out.... Received the following when building using java 10
WARNING: The option 'android.enableAapt2' is deprecated and should not
be used anymore.
Use 'android.enableAapt2=true' to remove this warning.
It will be removed at the end of 2018..

@steveamaza It works for me too. By the way, you should clean the android/app/build first after adding org.gradle.configureondemand=true in the gradle.properties.

Hello guys, any update about an official fix for this bug?

org.gradle.configureondemand=true( add it to grade.properties ) also worked for me, but first should clean project( delete  apk/app-release.apk )

After adding:
android.enableAapt2=false

You also need to restart Gradle by launching in a terminal in the  android directory:
./gradlew --stop

This is still happening in 0.55.4.

None of the solutions on this thread worked for me, still can't build my release.

See this PR for the official fix coming soon(tm).
https://github.com/facebook/react-native/pull/17967

so after uninstalling code push i was able to build APK with  this  solution #17967
Thanks.

Any solution?

@sashaba yeah you probably had to clean your build directory first.
@Dhrupal look at the PR I referenced a few comments up. Fix is coming there, hopefully.

I had the same issue as in https://github.com/react-navigation/react-navigation/issues/3315
I solved it this way:
Firstly bundled JS project with this command
react-native bundle --platform android --dev false --entry-file index.js --bundle-output android/app/src/main/assets/index.android.bundle --assets-dest android/app/src/main/res
and then generated signed APK on Android Studio, which fortunately worked for me
(I did not changed anything in gradle.properties

I'm not yet familiar with gradle so didn't want to mess with my build config and screw things up even more. Here's the terribly-hacky-but-reliable workaround I came up with - just delete the duplicate files as soon as they're created.
Run in another terminal:
watch -n 0.1 "yes | rm <ABSOLUTE_PATH>/android/app/build/intermediates/res/merged/release/drawable-mdpi/*"
And then start your build as you normally would.
Looking forward to seeing a release soon with the fix!

@hramos Which commit fixed it?

@dj-hedgehog https://github.com/facebook/react-native/commit/da6a5e0439c168147271ef66ad5ebbeebd6fce3b

This last workaround from @iswanj  doesn't work with RN 0.57.0-rc.0

org.gradle.configureondemand=true work for me. i just rm -rf build && ./gradlew assembleRelease and it worked.

RN 0.55.2
combination of
org.gradle.configureondemand=true
android.enableAapt2=false
worked for me

This should be fixed in 0.57 (see da6a5e0439c168147271ef66ad5ebbeebd6fce3b).

Until this got fixed, there is another workaround similar to solution proposed by @CFKevinRef. This solution also allows you to keep using AAPT2. Workaround consists of three steps

change default bundling output folder to be in src/ directory instead of build folder. You can do this by changing react properties at the top of your build.gradle (app build gradle)

ext.react = [
        bundleInRelease        : true,
        resourcesDirRelease   : "src/release/res"
]
apply from: "../react.gradle" /*Check file for more information*/
apply plugin: 'com.android.application'

please note that properties names are dynamic and depends on your target names, bundleIn, resourcesDir

Add generated files to git ignore, to keep your native resources folder clean
android/app/src/*/res/*/reactnative_*.png
android/app/src/*/res/*/node_modules_*.png
Reverse dependency between this react gradle task (bundling) and merging assets and resources.
This is the hardest part, you need to change this file {project_root_dir}/node_modules/react-native/react.gradle, In my case I copied this file to my project and keep updating it with each react release. The change is quite simple
replace

currentBundleTask.dependsOn("merge${targetName}Resources")
currentBundleTask.dependsOn("merge${targetName}Assets")

with
runBefore("merge${targetName}Resources", currentBundleTask)
runBefore("merge${targetName}Assets", currentBundleTask)

THIS WORKED FOR ME, THANK YOU!

This works for me on latest RN
I did have to remove android.enableAapt2=false  from android/gradle.properties first because I had added it there before as the temp fix.
Thanks RN team

Is this fix also added to 0.56.0 RN version?

The reason it didn't work for me was because my gradle.properties file was missing ...

React Native 0.48 I found solution for my issues, updating
distributionUrl=https\://services.gradle.org/distributions/gradle-4.10-all.zip
classpath 'com.android.tools.build:gradle:3.2.0'
and
https://stackoverflow.com/questions/44446523/unable-to-load-script-from-assets-index-android-bundle-on-windows/44476757#44476757

@marcosbenevides
Could you please clarify what is your version of React and React Native? And maybe you will provide your full react.gradle file. Thanks in advance!

@khemrajsharma you need to bump to the version 0.57.3.

@SandroMachado<EMAIL_ADDRESS>expects peer dependency<EMAIL_ADDRESS>which is still buggy

The issue seemed to disappeared after I stepped back to this and deleted my build folder and rebuilt.
    "react": "16.5.0",
    "react-native": "0.57.1"

I am using the 0.57.3 and didn't find any significant bug.

This should be fixed in 0.57 (see da6a5e0).

@hramos  Even if I replace the react.gradle with the content from that commit, I still get:
bundle: Done copying assets
...
....png: error: uncompiled PNG file passed as argument. Must be compiled first into .flat file...
error: failed parsing overlays.
...
> Failed to process resources, see aapt output above for details.

Do I miss something (I did clean)? Or I need more fixes from RN?
My current RN version is 0.56.0. I cannot upgrade to the 57 due to bags with the latest release.

@rumax
Do yo use react-native-toast-native library in your project? It was a reason of the issue with uncompiled PNG for me. I have a react native 0.57.0

org.gradle.configureondemand=true work for me. i just rm -rf build && ./gradlew assembleRelease and it worked. thank you for all the people in the thread who helped with this issue. you guys rock.

@r3wt Did you check official documentation before suggesting it? It clearly says:
(https://facebook.github.io/react-native/docs/signed-apk-android#generating-the-release-apk):
Note: Make sure gradle.properties does not include org.gradle.configureondemand=true as that will make the release build skip bundling JS and assets into the APK.

@valerybodak No. android.enableAapt2=false was used as a temporary solution, but now I'm trying to get rid of it because of other issues. And unfortunately I cannot find a working solution yet. Moreover it doesn't looks like a solution.

I had the same issue. But did not fix with - android.enableAapt2=false, as this has issues with other drawable resources in the project.
Fixed it with adding org.gradle.configureondemand=true in build.gradle, which shall disable the 'bundleReleaseJsAndAssets' task to run, which is the best solution and works in any condition. Hope this helps.

@iqbalshirol thanks for your suggestion. My project works again but what does org.gradle.configureondemand do? Doesn't configure the native libraries in node_modules? Is it necessary?
This is my list of native libraries at the moment:
"react-native-animatable": "^1.3.0",
    "react-native-config": "^0.11.5",
    "react-native-countdown-component": "^1.7.3",
    "react-native-dropdownalert": "^3.5.0",
    "react-native-firebase": "^5.0.0",
    "react-native-image-pan-zoom": "^2.1.9",
    "react-native-modal-overlay": "^1.2.3",
    "react-native-modalbox": "^1.6.0",
    "react-native-qrcode-svg": "^5.1.0",
    "react-native-splash-screen": "3.0.6",
    "react-native-svg": "^6.5.2",
    "react-native-table-component": "^1.1.8",
    "react-native-version-number": "^0.3.4",
    "react-native-version-up": "^1.0.9",
    "react-navigation": "^2.5.5",

Thank you!

android.enableAapt2=false

android.enableAapt2=false  not working for me.is there any other solution?

It is fixed in >=0.57.3.


Homebrew / Linuxbrew package of ema

I've created a Homebrew / Linuxbrew package for EMA.
See https://github.com/brewsci/homebrew-bio/pull/208
First install Homebrew on macOS or Linuxbrew on Linux, then run…
brew install brewsci/bio/ema

Would you like to update this formula with new releases of EMA? To update the formula, open a pull request that updates the tag and revision.
See https://github.com/brewsci/homebrew-bio/blob/master/Formula/ema.rb

Thanks! We just did a preprocessing fix that I'll release soon, and I'll be sure to update that formula.

I just opened a pull request for the new 6.0.1 release, and added this install option to the README. I'll close this issue for now; thanks again for your help.

Happy to help!


deps Upgrade iceberg to 1.4.0

Proposed changes
Apache Iceberg 1.4.0 has been released out, and it is good to upgrade Iceberg version from 1.1.0 to 1.4.0.

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

run buildall

run buildall

@morningman Could you please take a look? Thanks in advance.

run buildall


Measurement stopped working

Describe the bug
When I am doing initAuth() in pages / _app. Google analytics stopped working. Without initAuth() measurement works normally.
I don't know if it is necessary to add measurmentId to init ({}), but generally I don't know exactly where. Especially since I randomly added measurmentId to the object in many pleaces, but it didn't change anything.
Versions
next-firebase-auth version: ^1.0.0-canary.8
Firebase JS SDK: ^9.6.9
Next.js: latest
Update:
I just movedinit()to useEffect  without dependencies in _app.js and it started working normally.

Thanks! I spent so long trying to debug this

That fix worked!
However, I now am running into an issue on pages using withAuthUserTokenSSR({

Thanks for the issue.
This library just passes the firebaseClientInitConfig to firebase.initializeApp (see here), so the config structure should be the same.
Are you spelling measurementId correctly? Your issue description is missing an "e".
@davidwitten It's totally fine to initialize Firebase yourself like you're doing. If an app is already initialized, the library will just use that app. Just curious, does this approach work for you? I'm wondering if the analytics have to be initialized before next-firebase-auth or if it doesn't matter.
initAuth()
const firebaseApp = getApp()
const analytics = getAnalytics(firebaseApp)

function MyApp({ Component, pageProps }) {
    return <Component {...pageProps} />;
  }

We could initialize analytics automatically if measurementId is set in firebaseClientInitConfig. This would be a small change to in initFirebaseClientSDK.js. My only concern if is it would increase bundle size to import firebase/analytics.

@kmjennison I checked to spell, probably seven times, I was not this reason.

Maybe adding enable-analytics: true inside init can be solution? @kmjennison

It's possible. As I mention above, we would just need to ensure that doesn't increase the bundle size for people who don't use the analytics functionality.

Makes sense, is there any hack that we can do for now?
initAuth()
const firebaseApp = getApp()
const analytics = getAnalytics(firebaseApp)

did not work for me.

@davut You can initialize Firebase yourself. Here is some example code:
https://github.com/gladly-team/next-firebase-auth/discussions/61#discussioncomment-323977
That isn't a "hack". This library initializes Firebase as a convenience, but it's totally fine to do it yourself to customize things.

What if it firebase js version 9?
is import firebase from 'firebase/app' same as import firebase from 'firebase/compat/app' ? I am still getting the some errors with the version 9 :/.

Closing this: apps should initialize Firebase themselves when additional Firebase init customization is required.


Gen 01 rmd

Summary of changes

Merged the 09 and 10 Rmd components together,
updated challenge 3 to ggplot and gapminder.
re-formatted titles in previous 10 Rmd script.
updated challenge 4 to gapminder extension
tidy script
rename to 10

forgot to add a acknowledgement for https://rmd4sci.njtierney.com/ content


move wrap_litserve_start to utils

I would rather reserve conftest for fixtures and this (seems to be) general functionality move to another utils module

Originally posted by @Borda in https://github.com/Lightning-AI/LitServe/pull/190#discussion_r1705957686

hey i would like to take this up..

feel free to go ahead @ankitsharma07 🚀

feel free to go ahead @ankitsharma07 🚀

thanks.

@ankitsharma07 let me know if you need any help.

@aniketmaurya you can close this one


[SPARK-9512][SQL] keep the order of SortOrders when remove still-need-evaluate ordering…

… expressions from sort

cc @yhuai @marmbrus

Merged build triggered.

Merged build started.

Test build #39522 has started for   PR 7887 at commit c5a8459.

Test build #39522 has finished for   PR 7887 at commit c5a8459.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class PartitioningCollection(partitionings: Seq[Partitioning])

Merged build finished. Test PASSed.

Thanks for working on this, but after talking to @rxin we are just going to revert the change for now.  I've done that here #7906.

@cloud-fan @marmbrus Any reason on why didn't we go ahead with this bugfix for https://issues.apache.org/jira/browse/SPARK-9251? As whenever there is an expensive function in sort, it gets computed multiple times.


Status of the project

Hi, good morning!
I've seen the source code of this project and I wonder if you are still working on it? I wonder that cause I think this project can help me with some projects I have in mind (not comercial projects I mean, just university projects).
I would like to ask you too if there is support to audio (RTP) or not?
Thank you so much!

Ok, Thank you so much for you answer.


Changes from let to cached

Thanks to @adamleff and @someara to help out speeding up these tests!
From 6 mins back down to less then a min!

:+1:


[BUG] ORDER BY on array values produces incorrect results

What is the bug?
When a field that contains array values is used in an ORDER BY clause, the comparisons are performed using only the first element of the array values.
Consider an index with the following data:
{1, [1, 2]}
{2, [3, 4]}
{3, [1, 5]}
{4, [1, 2]}
{5, [2, 3]}

and this query:
SELECT x, y ORDER BY y;
{1, [1, 2]}
{3, [1, 5]}
{4, [1, 2]}
{5, [2, 3]}
{2, [3, 4]}

the expected results are:
{1, [1, 2]}
{4, [1, 2]}
{3, [1, 5]}
{5, [2, 3]}
{2, [3, 4]}

How can one reproduce the bug?
Steps to reproduce the behavior:

Create a new index and load the data above
Run the query above on the index

What is the expected behavior?
Comparisons are performed on the array values as a whole. An array comparison is performed element by element until a difference is found.
What is your host/environment?

OS: MacOS X (should not matter)
Version: 3.0 code base
Plugins: SQL plugin

Do you have any screenshots?
N/A
Do you have any additional context?
Issue #1300 had a change recently merged in that allows array values to be used in query evaluation and in the result set.

It looks like the OpenSearch engine is doing the sorting, not the SQL plugin.
Using the index and data from the description:
POST test3/_search
{
  "size": 10,
  "sort": {
    "y": {
      "order": "asc"
    }
  }
}

Produces this response:
{
  "took": 3,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 5,
      "relation": "eq"
    },
    "max_score": null,
    "hits": [
      {
        "_index": "test3",
        "_id": "ATXWtZIB72QJDYYHLMzM",
        "_score": null,
        "_source": {
          "x": 1,
          "y": [
            1,
            2
          ]
        },
        "sort": [
          1
        ]
      },
      {
        "_index": "test3",
        "_id": "AzXWtZIB72QJDYYHqczI",
        "_score": null,
        "_source": {
          "x": 3,
          "y": [
            1,
            5
          ]
        },
        "sort": [
          1
        ]
      },
      {
        "_index": "test3",
        "_id": "BDXWtZIB72QJDYYHy8wa",
        "_score": null,
        "_source": {
          "x": 4,
          "y": [
            1,
            2
          ]
        },
        "sort": [
          1
        ]
      },
      {
        "_index": "test3",
        "_id": "Q6i4xJIBxt0sLj_lfLXQ",
        "_score": null,
        "_source": {
          "x": 5,
          "y": [
            2,
            3
          ]
        },
        "sort": [
          2
        ]
      },
      {
        "_index": "test3",
        "_id": "AjXWtZIB72QJDYYHXszf",
        "_score": null,
        "_source": {
          "x": 2,
          "y": [
            3,
            4
          ]
        },
        "sort": [
          3
        ]
      }
    ]
  }
}

[Catch All Triage - 1, 2, 3, 4, 5]


merge from konsum-frontend-svelte

package.json

chore(deps): add ^10.8.0 remove ^10.7.10 (devDependencies.npm-pkgbuild)

.github/workflows/browser_ci.yml

chore: (jobs.test.steps)
chore: (jobs.test.steps)
chore: (jobs.test.steps)
chore: (jobs.test.steps)

:tada: This PR is included in version 1.31.19 :tada:
The release is available on:

npm package (@latest dist-tag)
v1.31.19
GitHub release

Your semantic-release bot :package::rocket:


Using Isolates with hive database error

I created an isolate function that consumes the hive database objects. While getting all objects from the database and giving them to the function flutter is throwing
Unhandled Exception: Invalid argument(s): Illegal argument in isolate message: (object extends NativeWrapper - Library:'dart:io' Class: _RandomAccessFileOpsImpl@13069316)

I have no idea how that could be.

Hi @Bahrom2101,
This issue doesn't seem to describe a bug or a feature request. Please see https://flutter.dev/community#community-grid for resources and asking questions like this. You may also get some help if you post it on Stack Overflow with a minimal code sample that clearly describes your problem.
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and we will reopen it.
Thank you

Hello, @maheshmnj I posted a question on stack overflow can you see it? https://stackoverflow.com/questions/72052779/i-am-trying-to-use-flutter-isolate-with-database-data-but-its-throwing-an-erro


fix: Improve argument processing and revert click version

fix: Improve argument processing and revert click version

@Wolmin @fhildeb Building and pushing to wagyu

lgtm @richtera 👍 Let's test with Wagyu and devnet (BLS change flow).

@richtera @fhildeb Tested on LUKSO Devnet (Validator index = 26). See https://app.clickup.com/t/2645698/DEV-5491?comment=90150028544728&threadedComment=90150029092182 and https://app.clickup.com/t/2645698/DEV-5491?comment=90150028544728&threadedComment=90150029092349


Add a display name placaholder

Hello, can you add {displayname} placeholder? for example a discord message is received in the staff channel, it gets the Effective name event.getMember().getEffectiveName();, if member is nicked, it gets the nick, if not it gets the name.

That is already the current behavior for both in-game and discord messages.


Classify some project files as XML

Also added disambiguation rule for .proj and .user.
CSCFG
https://github.com/search?utf8=✓&q=extension%3Acscfg+NOT+nothack&type=Code
(16.7K hits)
CSDEF
https://github.com/search?utf8=✓&q=extension%3Acsdef+NOT+nothack&type=Code
(12.7K hits)
CCPROJ
https://github.com/search?utf8=✓&q=extension%3Accproj+NOT+nothack&type=Code
(5K hits)
DEPPROJ
https://github.com/search?utf8=✓&q=extension%3Adepproj+NOT+nothack&type=Code
(505 hits)
NDPROJ
https://github.com/search?utf8=✓&q=extension%3Andproj+NOT+nothack&type=Code
(194 hits)
PROJ
https://github.com/search?utf8=✓&q=extension%3Aproj+(project+OR+Property+OR+Import+OR+xml+OR+xmlns)&type=Code
(35K hits)
SHPROJ
https://github.com/search?utf8=✓&q=extension%3Ashproj+NOT+nothack&type=Code
(13K hits)
USER
https://github.com/search?utf8=✓&q=extension%3Auser+(project+OR+Property+OR+Import+OR+xml+OR+xmlns)&type=Code
(693K hits)

@pchaigno, can you please review this? 😊

@Alhadis, is it ok to combine similar types in one PR? Alternatively, I can split them into separate ones. There are so many *proj types that are classify as XML.
Another option is that we disambiguate based on .*proj (suffix) pattern and make one rule matching /^(\s*)(<Project|<Import|<Property|<?xml|xmlns)/i to classify the XML. After that we can remove all those *proj listed under XML node in languages.yml to reduce the volume.

@Alhadis, is it ok to combine similar types in one PR?

Yes, it's okay. :) Don't worry, the way you've arranged this PR is perfectly acceptable: it's consistently XML-related.
Now, I'm not sure it'd be wise to register an extension as generic as .user as being an XML type... as you might expect from the sheer volume of results, there are probably numerous unrelated files with names ending in .user. Adding this extension would probably lead to a lot of false positives, so I'd recommend dropping it, or refining it to be more specific (.xproj.user, .csproj.user, etc...)
@lildude I'm still of the belief that XML deserves a separate classification mechanism based on doctype. The over-fragmentation of different file extensions is getting way out of hand...

@lildude I'm still of the belief that XML deserves a separate classification mechanism based on doctype. The over-fragmentation of different file extensions is getting way out of hand...

I agree, that list is becoming heeeawg and I imagine it'll keep getting bigger.
Gonna approve this PR in the meantime.


Add feature to hide metrics from clients/events view

I would like to see a feature in uchiwa to hide metrics from views
Expected Behavior
Cleaner view in clients/events dashboard, without metrics checks
Current Behavior
Overload of information, too many checks, because of not so useful in many cases info from metric checks
Possible Solution

on/off filter for metrics check
on/off filter based on some check definition variables, ex. :
"linux_load_avarage_metrics": {
"command": "metrics-load.rb",
"subscribers": [
"linux"
],
"output_type": "graphite",
"auto_tag_host": "yes",
"type": "metric",
"hide": "true",
"handlers": [ "relay" ],
"interval": 60
},

Hi @meloos, sorry for the delayed response, I was in vacation for the past few weeks!
It seems we already have an issue for this feature (https://github.com/sensu/uchiwa/issues/310) so I'll go ahead and close this one to prevent duplication.
For reference, I'll add this feature into the Uchiwa 0.26 milestone since it should now be relatively easy to implement.
Thanks