hashed IDs

I'm seeing this issue where the <id>s in my SVG mark-up are getting hashed, but the reference to that <id> in the <style> element is not, which is causing the image to break when using clipPath. Are these hashes necessary? Is it just for cache-busting? Can that be turned off as an option?
<style type="text/css">
	.logo-circle-left{fill:#ffffff;}
	.logo-circle-left-lines{fill:#ffffff;clip-path:url(#clip-1);}
	.logo-circle-right{fill:#ffffff;}
	.logo-circle-right-lines{fill:#ffffff;clip-path:url(#clip-2);}
	.logo-lines{fill:none;stroke:#ffffff;stroke-width:3;stroke-miterlimit:10;}
	.logo-star{fill:#000000;}
	.logo-text{fill:#ffffff;}
	.logo-bg-join{fill:#ffffff;}
</style>

<g>
	<defs>
		<circle id="SVGID_3____-341823852" cx="822.5" cy="384.4" r="384.4"></circle>
	</defs>
	<clipPath id="clip-2___-341823852">
		<use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#SVGID_3____-341823852" style="overflow:visible;"></use>
	</clipPath>
        ...
<g>

Thanks.

Hi @mikeriley131! No it's not for cache busting, it's to guard against weirdness that comes from having two elements with the same id on the page (e.g. the wrong one being used as a mask). You can disable it with a prop; see the README.

Ah, I completely missed that in the README. Sorry about that. Thanks for the reply.


Build fails on build.phonegap.com

I'm using
<gap:plugin name="cordova-plugin-admob-simple" source="npm" />
in the config.xml file and the build fails when that line is there, but the build works when I remove it.
I also tried it specifying the version:
<gap:plugin name="cordova-plugin-admob-simple" source="npm" spec="3.0.4" />

What platforms are you building for?

Android and iOS

You should use

Also make sure you have

If that doesn't work let me know the error it throws. Also I can upload a sample app.

Here is the error from the phonegap build log:
:preDexDebug
:dexDebug
UNEXPECTED TOP-LEVEL EXCEPTION:
com.android.dex.DexException: Multiple dex files define Lcom/google/android/gms/internal/zzpz;
at com.android.dx.merge.DexMerger.readSortableTypes(DexMerger.java:596)
at com.android.dx.merge.DexMerger.getSortedTypes(DexMerger.java:554)
at com.android.dx.merge.DexMerger.mergeClassDefs(DexMerger.java:535)
at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:171)
at com.android.dx.merge.DexMerger.merge(DexMerger.java:189)
at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:502)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:334)
at com.android.dx.command.dexer.Main.run(Main.java:277)
at com.android.dx.command.dexer.Main.main(Main.java:245)
at com.android.dx.command.Main.main(Main.java:106)
FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':dexDebug'.

com.android.ide.common.internal.LoggedErrorException: Failed to run command:
/android-sdk/build-tools/23.0.1/dx --dex --no-optimize --output /project/build/intermediates/dex/debug --input-list=/project/build/intermediates/tmp/dex/debug/inputList.txt
Error Code:
2
Output:

UNEXPECTED TOP-LEVEL EXCEPTION:
com.android.dex.DexException: Multiple dex files define Lcom/google/android/gms/internal/zzpz;
	at com.android.dx.merge.DexMerger.readSortableTypes(DexMerger.java:596)
	at com.android.dx.merge.DexMerger.getSortedTypes(DexMerger.java:554)
	at com.android.dx.merge.DexMerger.mergeClassDefs(DexMerger.java:535)
	at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:171)
	at com.android.dx.merge.DexMerger.merge(DexMerger.java:189)
	at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:502)
	at com.android.dx.command.dexer.Main.runMonoDex(Main.java:334)
	at com.android.dx.command.dexer.Main.run(Main.java:277)
	at com.android.dx.command.dexer.Main.main(Main.java:245)
	at com.android.dx.command.Main.main(Main.java:106)

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

BUILD FAILED
Total time: 1 mins 21.991 secs
/project/cordova/node_modules/q/q.js:126
throw e;
^
Error code 1 for command: /project/gradlew with args: cdvBuildDebug,-b,/project/build.gradle,-Dorg.gradle.daemon=true,-PcdvBuildMultipleApks=false

This looks more like a problem with the phonegap build tool or your configuration. The reason is probably because our plugin needs the google play services (and includes it, as it should) , and so does another plugin you use or you have included the jar file somewhere (am I right?). Then their implementation of gradle tries to include it twice instead of stripping out one of them.
See http://stackoverflow.com/questions/31224276/multiple-dex-files-define-lcom-google-android-gms-internal-zzau
Try contact phonegap about it.
Check what other plugins you use, and check their plugin.xml files.
You can see where we reference it here https://github.com/sunnycupertino/cordova-admob-sdklibs/blob/master/plugin.xml

You are correct.

The PushWoosh plugin requires gradle too and commenting it out allow me to include:
<gap:plugin name="cordova-plugin-admob-simple" source="npm" spec="3.0.4" />
and it builds fine.

Ok can I close this issue?

yes


filter_nones changed to use combinators

This is a bit more performant thanks to collect being optimized.

Heh, I tried this as well, but decided not to do it because the resulting code was longer instead of shorter. Especially the map to go from references to clones at the end is a bit ugly.
But if this is, even with that, more performant, sure, why not...

Finally, I'm back. :)
Ideally, there'd be draining iterator, which would allow us to get rid of the map and also avoid all those heap allocations. Maybe one day when I'm bored, I'll play with extending the API.

right—seems like a good idea, but would need a change to strason, I suppose

Correct, without changing strason, it's impossible.


Pull request gives 500 error after deleting "base" branch from old pull request

Gogs version (or commit ref): <IP_ADDRESS>9
Git version: 2.8.1.windows.1
Operating system: Windows Server 2012 R2
Database:

[ ] PostgreSQL
[ ] MySQL
[ ] SQLite

Can you reproduce the bug at http://try.gogs.io: https://try.gogs.io/apettit/test500error/

[X ] Yes (provide example URL)
[ ] No
[ ] Not relevant

Log gist:[E] NewPullRequest: testPatch: UpdateLocalCopy: Pull: exit status 1 - Your configuration specifies to merge with the ref 'refs/heads/branch_to_delete'

Description
You will get a 500 error if you delete a "base" branch of an old pull request.
Reproduction steps

Start with one branch "master" with a "test.txt" file
Make 2 additional branches "test" and "branch_to_delete" from master and push them
Change the contents of test.txtC
heck in on "test" branch and push
In GOGs create a pull request to merge the branch "test" into "branch_to_delete".  Do not accept or merge pull request at this time.
Delete branch "branch_to_delete" (origin/branch_to_delete)
In GOGs attempt to create a pull request to merge "test" into "master".  The initial diff will work, but when you click "create pull request" you will get a 500 error.

Additional info:  You also get a 500 error if you try to back into the first pull request to close it.

Patch has pushed to fix this issue, please test on develop branch or https://try.gogs.io.

Looks like it is working.  Thanks!


Explicitly configure rustfmt

Fixes #14442

Closing per the discussion at https://github.com/rust-lang/cargo/issues/14442#issuecomment-2429609979.


Change undefined argument handling in Layer[Group]/hasLayer()

undefined/null/false are not considered as special case anymore,
layer argument is always required, as per docs.
Previous excessive tolerance may lead to real errors get masked.
I've tracked the issue down to it's origin: #1282, but found mentioned there reasons weak.

Sorry, I've messed with commit, but will fix it asap.

May be better leave corresponding tests, if it's possible to express exception as expected result.

Looks there are still some conflicts?

Looks there are still some conflicts?

Fixed!


WIP: Salt reconfiguration to get rid of nginx on GCE

Instead, pass a bearer token for kubectl to the apiserver.

install libcap2-bin w/ apiserver
use setcap to allow the apiserver to bind to low numbered ports
set secure port for the apiserver to 443
Kubelet talk to port 443 on gce

I've tested that cluster creation works (as does kubectl for the new cluster) but haven't tested cluster upgrade or run e2e tests yet.

@smarterclayton @deads2k @liggitt - Hopefully this is more along the lines of what you were looking for than #6508.

heavy_breathing_cat.gif

Surfacing briefly.. I'm still OOO and probably won't get to this until
tomorrow or so. Access and time has been spottier than anticipated.
On Apr 9, 2015 1:37 PM, "Daniel Smith"<EMAIL_ADDRESS>wrote:

heavy_breathing_cat.gif
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/6618#issuecomment-91303454
.

@zmerlynn - don't worry. I wanted to get some early feedback from the RedHat folks on this. I don't want it merged before the 0.15 cut next week.

This looks awesome.

Rebased. PTAL.

LGTM (sorry, rebase again)

Rebased. I also updated some documentation files to talk about bearer tokens instead of basic auth. /cc @jlowdermilk

Two issues I'm working on.

The create external load balancer e2e test is failing due to a timeout:

Summarizing 1 Failure:

[Fail] Services [It] should be able to create a functioning external load balancer
/go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/test/e2e/service.go:339

Ran 35 of 40 Specs in 1244.857 seconds
FAIL! -- 34 Passed | 1 Failed | 1 Pending | 4 Skipped F0420 22:45:12.452252   99306 driver.go:94] At least one test failed

go run hack/e2e.go -v --up is failing to validate the e2e cluster

Running: /Users/robertbailey/Work/go/src/github.com/roberthbailey/kubernetes/hack/e2e-internal/../../cluster/../cluster/gce/../../cluster/../cluster/../cluster/gce/../../cluster/../cluster/../cluster/gce/../../cluster/../_output/dockerized/bin/darwin/amd64/kubectl get cs
2015/04/20 23:05:23 Error running up: exit status 1
2015/04/20 23:05:23 Error starting e2e cluster. Aborting.
exit status 1

go run hack/e2e.go --up is failing because of #7139 (and it's broken for me on the master branch as well).

@a-robinson pointed out that the reason the e2e test was failing was that I didn't have a firewall to allow http requests in my project. It's now passing as well:
$ go run hack/e2e.go -v --test --test_args="--ginkgo.focus=Service.*functioning external load balancer.*"
...
Ran 1 of 40 Specs in 61.238 seconds
SUCCESS! -- 1 Passed | 0 Failed | 0 Pending | 39 Skipped I0421 15:34:21.475133   42739 driver.go:96] All tests pass

Now that the latest gcloud release is out, we can move forward with this PR. I rebased on master and re-ran e2e tests. services.sh failed (with the same error I'm seeing in the latest run in Jenkins) but everything else passed.

LGTM.

Waiting on green, and feedback to https://groups.google.com/forum/#!topic/kubernetes-dev/nf9L-IeB56k


Update fail

I got a fail when i try to update VSCode, there is the log:
Apr 25 10:35:21.498 INFO Starting: C:\Program Files\Microsoft VS Code\Code.exe, false
Apr 25 10:35:21.512 INFO Checking for running Code.exe processes... (attempt 1)
Apr 25 10:35:21.512 INFO Code.exe is running, wait a bit
Apr 25 10:35:22.000 INFO Checking for running Code.exe processes... (attempt 2)
Apr 25 10:35:22.004 INFO Code.exe is running, wait a bit
Apr 25 10:35:22.504 INFO Checking for running Code.exe processes... (attempt 3)
Apr 25 10:35:22.508 INFO Code.exe is running, wait a bit
Apr 25 10:35:23.008 INFO Checking for running Code.exe processes... (attempt 4)
Apr 25 10:35:23.012 INFO Code.exe is running, wait a bit
Apr 25 10:35:23.512 INFO Checking for running Code.exe processes... (attempt 5)
Apr 25 10:35:23.516 INFO Code.exe is running, wait a bit
Apr 25 10:35:24.016 INFO Checking for running Code.exe processes... (attempt 6)
Apr 25 10:35:24.020 INFO Code.exe is running, wait a bit
Apr 25 10:35:24.520 INFO Checking for running Code.exe processes... (attempt 7)
Apr 25 10:35:24.524 INFO Code.exe is running, wait a bit
Apr 25 10:35:25.024 INFO Checking for running Code.exe processes... (attempt 8)
Apr 25 10:35:25.029 INFO Code.exe is running, wait a bit
Apr 25 10:35:25.529 INFO Checking for running Code.exe processes... (attempt 9)
Apr 25 10:35:25.533 INFO Code.exe is running, wait a bit
Apr 25 10:35:26.033 INFO Checking for running Code.exe processes... (attempt 10)
Apr 25 10:35:26.038 INFO Code.exe is running, wait a bit
Apr 25 10:35:26.538 INFO Checking for running Code.exe processes... (attempt 11)
Apr 25 10:35:26.542 INFO Code.exe is running, wait a bit
Apr 25 10:35:27.042 INFO Checking for running Code.exe processes... (attempt 12)
Apr 25 10:35:27.046 INFO Code.exe is running, wait a bit
Apr 25 10:35:27.546 INFO Checking for running Code.exe processes... (attempt 13)
Apr 25 10:35:27.550 INFO Code.exe is running, wait a bit
Apr 25 10:35:28.050 INFO Checking for running Code.exe processes... (attempt 14)
Apr 25 10:35:28.054 INFO Code.exe is running, wait a bit
Apr 25 10:35:28.554 INFO Checking for running Code.exe processes... (attempt 15)
Apr 25 10:35:28.558 INFO Code.exe is running, wait a bit
Apr 25 10:35:29.058 INFO Checking for running Code.exe processes... (attempt 16)
Apr 25 10:35:29.062 INFO Code.exe is running, wait a bit
Apr 25 10:35:29.562 INFO Checking for running Code.exe processes... (attempt 17)
Apr 25 10:35:29.566 INFO Code.exe is running, wait a bit
Apr 25 10:35:30.067 INFO Checking for running Code.exe processes... (attempt 18)
Apr 25 10:35:30.071 INFO Code.exe is running, wait a bit
Apr 25 10:35:30.571 INFO Checking for running Code.exe processes... (attempt 19)
Apr 25 10:35:30.575 INFO Code.exe is running, wait a bit
Apr 25 10:35:31.075 INFO Checking for running Code.exe processes... (attempt 20)
Apr 25 10:35:31.079 INFO Gave up waiting for Code.exe to exit
Apr 25 10:35:50.374 ERRO Failed to get process file name

/duplicate #47815


hunt packet search jobs should skip sessions for which no PCAP exists

Elasticsearch version: 6.4.1
Moloch version: 1.6.0
OS name and version: Linux, debian testing (buster)
How was Moloch built/installed: easybutton inside of docker
Provide logs, stack traces and steps to reproduce:

Create session entries in the database with no associated PCAP file (for example, insert data via logstash or some other way)
Go to the hunts tab, and submit a hunt packet search job

You will see the viewer app crash, with the following backtrace:
Tue, 30 Oct 2018 14:08:12 GMT analyst POST /hunt 200 369 bytes 856.047 ms
url.js:103
    throw new TypeError('Parameter "url" must be a string, not ' + typeof url);
    ^
TypeError: Parameter "url" must be a string, not undefined
    at Url.parse (url.js:103:11)
    at Object.urlParse [as parse] (url.js:97:13)
    at /data/moloch/viewer/viewer.js:707:20
    at /data/moloch/viewer/viewer.js:651:14
    at exports.get (/data/moloch/viewer/db.js:465:7)
    at respond (/data/moloch/node_modules/elasticsearch/src/lib/transport.js:327:9)
    at checkRespForFailure (/data/moloch/node_modules/elasticsearch/src/lib/transport.js:267:7)
    at HttpConnector.<anonymous> (/data/moloch/node_modules/elasticsearch/src/lib/connectors/http.js:165:7)
    at IncomingMessage.wrapper (/data/moloch/node_modules/lodash/lodash.js:4949:19)
    at emitNone (events.js:111:20)

After some experimentation, this seems to be quite similar to issue #878 (see also commit 4cdc44108e). It looks like the hunt job should skip sessions with no fileids set.

hunt should do the ES query with an exists fileId sot it only process sessions with files associated

I tested this patch, seems to fix the problem for me.
hunt_fileid_exists_patch_946.txt

@mmguero Thank you so much for figuring out the cause of the bug and providing a fix! Do you want to submit a pull request with that fix for the fake internet points?

@mmguero Thank you so much for figuring out the cause of the bug and providing a fix! Do you want to submit a pull request with that fix for the fake internet points?

Sure, I'll submit a pull request.


Potential issues with qasm parser

Informations

Qiskit version: 0.23.2
Python version: 3.7.9
Operating system: Windows 10

What is the current behavior?

Some QuantumCircuits containing Unicode characters cannot be saved to file correctly.
QuantumCircuit.from_qasm_str and .from_qasm_file fails to parse some circuits that were saved to string/file without error.

Steps to reproduce the problem
For 1) run, for example:
from qiskit.circuit.library import TwoLocal
vcircuit = TwoLocal(2, ["ry"], "cz", "linear", 1)
vcircuit.qasm(filename="file.txt")

Circuit contains the letter „θ“ (U+03B8) but works fine apart from this issue.
For 2) run, for example:
from qiskit import QuantumCircuit
from qiskit.circuit.library import ZFeatureMap
fcircuit = ZFeatureMap(2)
fcircuit.qasm(filename="file.txt")
QuantumCircuit.from_qasm_file("file.txt")

This circuit is saved to file without error, but cannot be parsed successfully from it. (It intentionally has unassigned parameters which seems to be part of the problem.)
What is the expected behavior?
Circuits should be saved and parsed without error.
Suggested solutions
For 1) it seems to work when I store the qasm string manually to file. I.e. run only qasm() on the circuit and write the result to a file using utf-8 encoding. This is probably an encoding problem somewhere.

An example issue:
import qiskit as qk
qk.QuantumCircuit.from_qasm_str("qreg q[1];U(0.0, 0.0, 0.0) q[0];")

String parsing doesn't play nice with 1 of 2 of the core OpenQASM gates, U, however if you wrap it in a definition it works just fine:
string = """
qreg q[1];
gate u(a, b, c) d {U(a,b,c) d;}
u(0.0, 0.0, 0.0) q[0];
"""
qk.QuantumCircuit.from_qasm_str(string)

Problem 2) was already resolved by #5705 which raises an error when parameterized circuits are converted to qasm. Hopefully, OpenQASM 3 will be able to represent parameterized circuits soon.
@dahlend This worked for me: qk.QuantumCircuit.from_qasm_str('include "qelib1.inc";qreg q[1];U(0.0, 0.0, 0.0) q[0];')
I just included qelib1.inc. but I think you're right that this should work without including anything since U is a core gate.

I'm going to close this issue now, because the exporter reliably emits a correct error that circuits with unbound parameters can't be represented in OpenQASM 2.  For what it's worth, the OpenQASM 3 exporter (qiskit.qasm3.dumps) successfully exports both of these circuits, and the importer (qiskit.qasm3.loads) can load them back into Qiskit again.
If there's more to say, please feel free to open a new issue.


Appending arbitrary fields to form?

I'd like to achieve functionality similar to the Add/Delete buttons on arrays, but instead of adding the same field to the form every time the button is clicked, I'd like the user to be able to add a field from an arbitrary list of fields.
Would something like this require support for oneOf (#52)? Would this be possible to do by creating a custom field?

Yes, we'd need support for anyOf/oneOf to achieve this "automatically". It should be possible to create a custom SchemaField, where you can hook into the way JSON schemas are mapped to field components, but this is likely to be pretty tricky...

Another strategy to generate a new schema with the a new field added. The flow would be:

An initial schema is passed to the Form
Use select something
The onChange event is triggered with this new value
An external function receive this information and computes a new schema accordingly
That function updates the schema prop passed to the Form instance, which now reflects the appropriate new schema fields

Might be worth a try.

That's a good idea, I'll give that a shot. I was going to try just adding a new Form instance to the page whenever a user wanted to add a new field, which seemed fine since most of the fields are more complex fields and not single-input fields. Is there any reason why that approach would be worse than the one you suggested?

That'd move the complexity to listening to many Form onChange events and reconcile all the different forms data, but yeah that could work too.

Just wanted to let you know that your suggestion above was pretty much exactly what I needed. I have a form that's separate from the one that I'm building up that allows the user to select which field they'd like to add to the form. Each selection has a schema associated with it, so when the user selects a field, I add that field's schema to the form schema and re-render the form.
I'm relatively new to React so the "update state then re-render" cycle wasn't very intuitive to me, though the solution seems fairly obvious now :P

I'm glad you found a solution to your problem using the current API. I'm closing this now, and if you have any pointer to your implementation, feel free to link it here so other people can take inspiration :)


Continuation of work on validation/mapFile mechanism -- Wind0ze workarounds!

Added blocksdb_mapfile_tests to test suite in order to see what happens when a block file grows.
Blocks::DB::blkFileHasGrown also added, and called from code that allocates blocks to notify that future mmaps in Blocks::DBPrivate should remap the file because it has grown.
Addressed windows file/locking issue by forcing all windows blk files to
pre-allocate to 128MB. (Otherwise, windows mmap's don't see updated file sizes until all extant
mmaps are closed!)
Added a custom Windows-only class that handles mmaping with sharing enabled.  Not all boost versions do this properly and I was getting tests failing.
Added an FOPEN() macro which on Window calls _fopen_s() with FILE_SHARING enabled so that windows file opens don't barf on files that are mmap'd. On other platforms FOPEN()->fopen()
Addressed a few minor compile warnings
All of the above makes tests pass on Windows again -- if using mmap'd files.

Note this is just a reference implementation of what you might need to do to get Windows to play nice with memory-mapped files.
You don;t have to merge it as-is.  Feel free to just use it for illustrative purposes on how to work around windows issues with memory mapped files.


Virtual Dispose in NancyBootstrapperBase

This PR makes made NancyBootstrapperBase.Dispose() virtual so it can be overridden in deriving classes. This makes it easier for StructureMapNancyBootstrapper and others to dispose resources other than the ApplicationContainer.

This way you'd have to either re-implement the disposing and initialised logic and make sure you dispose the container (unless you call base as well). Wouldn't it be better to have a separate overload that's called for additional resources?

@khellang True. I've changed it to be more according to this guide, although there might be some confusion over the collision between the field disposing and the parameter to Disposing(). However, since this is a known and common pattern, I think naming the parameter disposing is important and that if anything should change, then it is the name of the field.

Thanks @asbjornu! :heart:


Avoid undelivered notifications error

Maybe closes: https://github.com/snowplow/snowplow-javascript-tracker/issues/1306
I have yet to validate that this change fixes anything. I plan to test this and see if it reduces the error rate. I will comment once I've tested this in production and confirmed that it resolves the errors.
Based on the ResizeObserver documentation, I suspect that calling readBrowserProperties() forces a synchronous layout, which then enqueues a new resize observer notification if the body size changes when the layout is re-calculated.

Thanks for your pull request. Is this your first contribution to a Snowplow open source project? Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://docs.snowplowanalytics.com/docs/contributing/contributor-license-agreement/ to learn more and sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

We should probably make getBrowserProperties only do the expensive stuff conditionally as well; 1/3 callers don't even use the expensive viewport/documentSize values and it's when the tracker first loads so probably a bad time to be forcing reflow.

I'm happy to make that change if you're open to it, I can do it in a separate PR.

I signed it!

Confirmed! @AngusMorton has signed the Contributor License Agreement. Thanks so much.


Latest development version broken (NoClassDefFoundError BlockModelRenderer)

I use VanillaFix latest development version (VanillaFix-1.0.10-104).
https://pastebin.com/eAcHM5bZ

We know about this problem, and it's not related to Optifine (happens with just VanillaFix when running outside of dev). We'll have to fix it before releasing to CurseForge. Until then you can use the CurseForge release.

Fixed


Container envs not updated from vault if previous deploy failed.

We had an issue where a secret was added to the vault and a service in a stack, but there was a typo in the secret that caused the container to crash and the stack deploy (eventually) failed.
The secret was then updated in the vault to fix the problem, but nothing we did would update it to the container. We tried was redeploying the stack again (which kept failing as the service was in restart loop), deploying the specific service itself again,  stopping and starting the service, stopping and removing the container and image directly from docker and deploying again after that. Nothing did the trick.
Only after kontena-agent was restarted the env got immediately updated and the container started.

We tried was redeploying the stack again (which kept failing as the service was in restart loop)

How exactly did the stack deploy fail? With a timeout error? Are you using wait_for_port, and the agent is busy waiting for the port to respond while the service is in the restart loop?
If yes, then this could be something along the lines of #2415, where the agent is stuck processing multiple queued up copies of the old service deploy, and thus fails to pick up the new updated service deploy. That is fixed in 1.4 for the case of wait_for_port.


String and char literals

String and char literals are tricky, b/c of escape sequences. Lexer should not interpret escape sequences unless absolutely necessary: it is the work of the validator to check them and to convert them to a real literal.

[ ] fix the lexer itself
[ ] create a validator
[ ] tests

@matklad we now have validators and tests. Does something still need to be fixed in the lexer?
Missing validators are:

Raw string
Raw byte string
Byte string
Byte

Yeah, I think this should be closed!
@aochagavia could you open a separate issue for byte strings and bytes, with pointers to existing infra?
Off the top of my head, I don't think we need any validation for raw strings: they are raw, so anything goes.

oh, you already did, that's #223 :)

Regarding raw strings... We should at least check that they are properly closed, right?

oh, you are right, that one we must check!


Update to current vue-i18n-extract version

Module versions (please complete the following information):

"@vue/cli-service": "~4.5.0"
vue-cli-plugin-i18n: 2.3.1

Expected behavior
Should not cause security alerts by depending on an exact but outdated version of vue-i18n-extract (1.0.2) The current version of vue-i18n-extract fixes the security issue.
Screenshots

This would be quite appreciated. Any updates here @icemac ?

@larsschellhas The main branch still depends on version 1.0.2 and I see no PR to fix this. I am just the one who reported the issue because I am using this package.

I've created a pull request for this update.


failoverPriority and missing IstioEndpoint labels in Multi-Primary on different networks

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
I have a working Multi-Primary on different networks setup that consists of two k8s clusters, almost identical to the setup described here except deployed with helm. Locality load balancing using basic "just enabled", distribute and failover settings works perfectly. But the failoverPriority setting doesn't seem to work at all. After debugging this issue for a bit, it seems to me that there are just too few labels added to IstioEndpoint objects belonging to endpoints from remote cluster.
Here's a dump of IstioEndpoint.Labels of a local endpoint from inside this function. Basically every label from the workload is here and also the topology labels from underlying node are merged in correctly.
app.kubernetes.io/instance=httpbin
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=httpbin
app.kubernetes.io/version=0.0.0
helm.sh/chart=httpbin-0.0.0
istio.io/rev=stable
kubernetes.io/hostname=$hostname1
pod-template-hash=***
security.istio.io/tlsMode=istio
service.istio.io/canonical-name=httpbin
service.istio.io/canonical-revision=0.0.0
topology.istio.io/cluster=$cluster1
topology.istio.io/network=$network1
topology.istio.io/subzone=$subzone1
topology.kubernetes.io/region=$region1
topology.kubernetes.io/zone=$zone1

And here's a dump of IstioEndpoint.Labels of an endpoint discovered from remote kube-apiserver from inside this function. There are just two istio.io labels. And if i try using failoverPriority with those, it works just fine.
topology.istio.io/cluster=$cluster2
topology.istio.io/network=$network2

And as an extra, here's a dump of IstioEndpoint.Labels of an endpoint of ServiceEntry with defined locality.
topology.istio.io/cluster=$cluster1
topology.istio.io/subzone=$subzone3
topology.kubernetes.io/region=$region2
topology.kubernetes.io/zone=$zone3

At the same time, the locality data is correct inside all the LocalityLbEndpoints objects. I guess that's why basic locality LB, failover and distribute methods work despite missing labels.
Looking at /debug/endpointShardz everything seems to be fine. All the labels are present here.
        "Kubernetes/$cluster1": [
          {
            "Labels": {
              "app.kubernetes.io/instance": "httpbin",
              "app.kubernetes.io/managed-by": "Helm",
              "app.kubernetes.io/name": "httpbin",
              "app.kubernetes.io/version": "0.0.0",
              "helm.sh/chart": "httpbin-0.0.0",
              "istio.io/rev": "stable",
              "kubernetes.io/hostname": "$hostname1",
              "pod-template-hash": "***",
              "security.istio.io/tlsMode": "istio",
              "service.istio.io/canonical-name": "httpbin",
              "service.istio.io/canonical-revision": "0.0.0",
              "topology.istio.io/cluster": "$network1",
              "topology.istio.io/network": "$network1",
              "topology.istio.io/subzone": "$subzone1",
              "topology.kubernetes.io/region": "$region1",
              "topology.kubernetes.io/zone": "$zone1"
            },
            "Address": "***",
            "ServicePortName": "http",
            "ServiceAccount": "spiffe://cluster.local/ns/***/sa/default",
            "Network": "$network1",
            "Locality": {
              "Label": "$region1/$cluster1/$subzone1",
              "ClusterID": "$cluster1"
            },
            "EndpointPort": 80,
            "LbWeight": 0,
            "TLSMode": "istio",
            "Namespace": "***",
            "WorkloadName": "httpbin",
            "HostName": "",
            "SubDomain": "",
            "HealthStatus": 1,
            "NodeName": "$hostname1"
          }
        ],
        "Kubernetes/$cluster2": [
          {
            "Labels": {
              "app.kubernetes.io/instance": "httpbin",
              "app.kubernetes.io/managed-by": "Helm",
              "app.kubernetes.io/name": "httpbin",
              "app.kubernetes.io/version": "0.0.0",
              "helm.sh/chart": "httpbin-0.0.0",
              "istio.io/rev": "stable",
              "kubernetes.io/hostname": "$hostname2",
              "pod-template-hash": "***",
              "security.istio.io/tlsMode": "istio",
              "service.istio.io/canonical-name": "httpbin",
              "service.istio.io/canonical-revision": "0.0.0",
              "topology.istio.io/cluster": "$cluster2",
              "topology.istio.io/network": "$network2",
              "topology.istio.io/subzone": "$subzone2",
              "topology.kubernetes.io/region": "$region1",
              "topology.kubernetes.io/zone": "$zone2"
            },
            "Address": "***",
            "ServicePortName": "http",
            "ServiceAccount": "spiffe://cluster.local/ns/***/sa/default",
            "Network": "$network2",
            "Locality": {
              "Label": "$region1/$zone2/$subzone2",
              "ClusterID": "$cluster2"
            },
            "EndpointPort": 80,
            "LbWeight": 0,
            "TLSMode": "istio",
            "Namespace": "***",
            "WorkloadName": "httpbin",
            "HostName": "",
            "SubDomain": "",
            "HealthStatus": 1,
            "NodeName": "$hostname2"

Is it possible that all the labels are somehow lost due to some east-west gateway related endpoint transformations? Or maybe there's some misconfiguration? Should there even be any more labels in this setup with east-west gateways?
I'd appreciate any help debugging this further.
Thanks!
Version
$ istioctl version
client version: 1.20.2
control plane version: 1.20.2
data plane version: 1.20.2 (11 proxies)
$ kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.27.6
Kustomize Version: v5.0.1
Server Version: v1.27.7
$ helm version --short
v3.12.2+g1e210a2

Additional Information
No response

I assume this is due to https://github.com/istio/istio/blob/954dcf909cb451095fdc06102e29da959a3ac5b4/pilot/pkg/xds/endpoints/ep_filters.go#L129-L136.
I don't really know what we can do here. The only info we know about the gateway is what IP and cluster its in, we don't know anything about the region, zone, etc. Region perhaps could be implied by the cluster (pretty weird to have a cluster span regions...) but that is all a bit heuristic
WDYT @stevenctl @hzxuzhonghu ?
Although I don't understand why failover works

@howardjohn, thanks! I think you're exactly right about reason.
Here's a quick hack i tested:
diff --git a/pilot/pkg/xds/endpoints/ep_filters.go b/pilot/pkg/xds/endpoints/ep_filters.go
index ce89e724d0..040fcf9fea 100644
--- a/pilot/pkg/xds/endpoints/ep_filters.go
+++ b/pilot/pkg/xds/endpoints/ep_filters.go
@@ -113,6 +113,33 @@ func (b *EndpointBuilder) EndpointsByNetworkFilter(endpoints []*LocalityEndpoint
                        splitWeightAmongGateways(weight, gateways, gatewayWeights)
                }

+               // Find common labels for all IstioEndpoints
+               commonIEpLabels := labels.Instance{}
+               if len(ep.istioEndpoints) > 0 {
+                       for k, v := range ep.istioEndpoints[0].Labels {
+                               labelIsCommon := true
+                               for i := 1; i < len(ep.istioEndpoints); i++ {
+                                       label, ok := ep.istioEndpoints[i].Labels[k]
+
+                                       if !ok {
+                                               labelIsCommon = false
+
+                                               break
+                                       }
+
+                                       if label != v {
+                                               labelIsCommon = false
+
+                                               break
+                                       }
+                               }
+
+                               if labelIsCommon {
+                                       commonIEpLabels[k] = v
+                               }
+                       }
+               }
+
                // Sort the gateways into an ordered list so that the generated endpoints are deterministic.
                gateways := maps.Keys(gatewayWeights)
                gateways = model.SortGateways(gateways)
@@ -132,7 +159,7 @@ func (b *EndpointBuilder) EndpointsByNetworkFilter(endpoints []*LocalityEndpoint
                                Locality: model.Locality{
                                        ClusterID: gw.Cluster,
                                },
-                               Labels: labelutil.AugmentLabels(nil, gw.Cluster, "", "", gw.Network),
+                               Labels: labelutil.AugmentLabels(commonIEpLabels, gw.Cluster, "", "", gw.Network),
                        }

                        // Generate the EDS endpoint for this gateway.

I also added another replica in remote cluster. Here are the dumps of IstioEndpoint.Labels again from inside this function.
Remote endpoint A:
app.kubernetes.io/instance=httpbin
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=httpbin
app.kubernetes.io/version=0.0.0
helm.sh/chart=httpbin-0.0.0
istio.io/rev=stable
kubernetes.io/hostname=$hostname1
pod-template-hash=***
security.istio.io/tlsMode=istio
service.istio.io/canonical-name=httpbin
service.istio.io/canonical-revision=0.0.0
topology.istio.io/cluster=$cluster2
topology.istio.io/network=$network2
topology.istio.io/subzone=$zone2-$rack1
topology.kubernetes.io/region=$region1
topology.kubernetes.io/zone=$zone2

Remote endpoint B:
app.kubernetes.io/instance=httpbin
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=httpbin
app.kubernetes.io/version=0.0.0
helm.sh/chart=httpbin-0.0.0
istio.io/rev=stable
kubernetes.io/hostname=$hostname2
pod-template-hash=***
security.istio.io/tlsMode=istio
service.istio.io/canonical-name=httpbin
service.istio.io/canonical-revision=0.0.0
topology.istio.io/cluster=$cluster2
topology.istio.io/network=$network2
topology.istio.io/subzone=$zone2-$rack2
topology.kubernetes.io/region=$region1
topology.kubernetes.io/zone=$zone2

Now, with this hack, failoverPriority works just fine on any of those labels.

Is it actually reasonable to passthrough some labels from discovered workloads to gateway endpoint? This is the most convenient option in my case. But this is probably wrong for different cases.
Alternatively, maybe there should be a way to pass those labels manually, for example through discovered k8s Service as was suggested, or something like that.

Does failover really work but failoverPriority doesn't? that doesn't seem to make sense.
Automatically using the common labels feels like it will be problematic outside if simple cases. Especially if we talk about arbitrary labels not well know ones

Does failover really work but failoverPriority doesn't? that doesn't seem to make sense.

Yes, it does work. Actually, locality looks totally "correct" outside of IstioEndpoint objects.
Here is how priority looks for a few endpoints from examples above.
DestinationRule looks like this, with just localityLbSetting.enabled: true and nothing else.
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  annotations:
    meta.helm.sh/release-name: httpbin
    meta.helm.sh/release-namespace: ***
  labels:
    app.kubernetes.io/instance: httpbin
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: httpbin
    app.kubernetes.io/version: 0.0.0
    helm.sh/chart: httpbin-0.0.0
  name: httpbin
  namespace: ***
spec:
  host: httpbin.***.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
    outlierDetection:
      baseEjectionTime: 1m
      consecutive5xxErrors: 1
      interval: 15s

And here is proxy-config endpoints
 $ istioctl pc endpoints -n *** httpbin-5df8f77f4f-z55l5 --cluster 'outbound|80||httpbin.***.svc.cluster.local' --output json | grep locality -A 3 -B 1
                "weight": 1,
                "locality": {
                    "region": "$region1",
                    "zone": "$zone1",
                    "subZone": "$zone1-$rack1"
--
                "priority": 1,
                "locality": {
                    "region": "$region1",
                    "zone": "$zone2",
                    "subZone": "$zone2-$rack1"
--
                "priority": 2,
                "locality": {
                    "region": "$region2",
                    "zone": "$zone3",
                    "subZone": "$zone3-$rack1"

First endpoint with priority 0 is local, the one in the same cluster. Second endpoint with priority 1 is in the same region, but in a different zone. Third endpoint with priority 2 is a ServiceEntry with a made up different region.
Basically the only thing that doesn't work is failoverPriority. I guess because it depends on the labels, not the locality data.

Ah I get it now. Despite the gateway endpoints have the fake Locality set (https://github.com/istio/istio/blob/954dcf909cb451095fdc06102e29da959a3ac5b4/pilot/pkg/xds/endpoints/ep_filters.go#L129-L136), the failover code is reading the envoy Endpoint info which has locality set.
So I think what this is basically doing, and what we should do for failoverPriority is what @stevenctl mentioned: "When not homogeneous, expand into multiple addresses and our existing re-balancing calculation can maybe deal with this to some degree?"
That might be as simple as copying the labels over in https://github.com/istio/istio/blob/954dcf909cb451095fdc06102e29da959a3ac5b4/pilot/pkg/xds/endpoints/ep_filters.go#L130 but I am not sure, would need some testing.

Basically, logically if I have 10 remote network endpoints, we would have 10 endpoints in envoy, all which can have the original metadata. We happen to optimize this down to 1 endpoint with weight=10, but we could split it up (and already do with locality).
Note this does actually have a small flaw: I can have client in zone1, gateway in zone2, and server in zone1; the current/proposed approach would not consider that the gateway is in another zone. Solving that seems extremely challenging though

Basically, logically if I have 10 remote network endpoints, we would have 10 endpoints in envoy, all which can have the original metadata.

Here's a very rough PoC. The idea is, instead of aggregating weight on gateway endpoints, we create separate endpoints for everything. In the real world, this should probably be aggregated by matching label map or something.
diff --git a/pilot/pkg/xds/endpoints/ep_filters.go b/pilot/pkg/xds/endpoints/ep_filters.go
index ce89e724d0..297a78934f 100644
--- a/pilot/pkg/xds/endpoints/ep_filters.go
+++ b/pilot/pkg/xds/endpoints/ep_filters.go
@@ -27,7 +27,6 @@ import (
 	labelutil "istio.io/istio/pilot/pkg/serviceregistry/util/label"
 	"istio.io/istio/pkg/cluster"
 	"istio.io/istio/pkg/config/labels"
-	"istio.io/istio/pkg/maps"
 	"istio.io/istio/pkg/network"
 )

@@ -63,9 +62,6 @@ func (b *EndpointBuilder) EndpointsByNetworkFilter(endpoints []*LocalityEndpoint
 			},
 		}

-		// Create a map to keep track of the gateways used and their aggregate weights.
-		gatewayWeights := make(map[model.NetworkGateway]uint32)
-
 		// Process all the endpoints.
 		for i, lbEp := range ep.llbEndpoints.LbEndpoints {
 			istioEndpoint := ep.istioEndpoints[i]
@@ -109,53 +105,46 @@ func (b *EndpointBuilder) EndpointsByNetworkFilter(endpoints []*LocalityEndpoint
 				continue
 			}

-			// Apply the weight for this endpoint to the network gateways.
-			splitWeightAmongGateways(weight, gateways, gatewayWeights)
-		}
-
-		// Sort the gateways into an ordered list so that the generated endpoints are deterministic.
-		gateways := maps.Keys(gatewayWeights)
-		gateways = model.SortGateways(gateways)
-
-		// Create endpoints for the gateways.
-		for _, gw := range gateways {
-			epWeight := gatewayWeights[gw]
-			if epWeight == 0 {
+			// Create separate endpoint for each gateway and attach all the labels to it.
+			for _, gw := range gateways {
+				epWeight := weight / uint32(len(gateways))
+				if epWeight == 0 {
 				log.Warnf("gateway weight must be greater than 0, scaleFactor is %d", scaleFactor)
-				epWeight = 1
-			}
-			epAddr := util.BuildAddress(gw.Addr, gw.Port)
-
-			// Generate a fake IstioEndpoint to carry network and cluster information.
-			gwIstioEp := &model.IstioEndpoint{
-				Network: gw.Network,
-				Locality: model.Locality{
-					ClusterID: gw.Cluster,
-				},
-				Labels: labelutil.AugmentLabels(nil, gw.Cluster, "", "", gw.Network),
-			}
+					epWeight = 1
+				}
+				epAddr := util.BuildAddress(gw.Addr, gw.Port)
+
+				// Generate a fake IstioEndpoint to carry network and cluster information.
+				gwIstioEp := &model.IstioEndpoint{
+					Network: gw.Network,
+					Locality: model.Locality{
+						ClusterID: gw.Cluster,
+					},
+					Labels: labelutil.AugmentLabels(ep.istioEndpoints[i].Labels, gw.Cluster, "", "", gw.Network),
+				}

-			// Generate the EDS endpoint for this gateway.
-			gwEp := &endpoint.LbEndpoint{
-				HostIdentifier: &endpoint.LbEndpoint_Endpoint{
-					Endpoint: &endpoint.Endpoint{
-						Address: epAddr,
+				// Generate the EDS endpoint for this gateway.
+				gwEp := &endpoint.LbEndpoint{
+					HostIdentifier: &endpoint.LbEndpoint_Endpoint{
+						Endpoint: &endpoint.Endpoint{
+							Address: epAddr,
+						},
+					},
+					LoadBalancingWeight: &wrappers.UInt32Value{
+						Value: epWeight,
 					},
-				},
-				LoadBalancingWeight: &wrappers.UInt32Value{
-					Value: epWeight,
-				},
-				Metadata: &core.Metadata{},
+					Metadata: &core.Metadata{},
+				}
+				// TODO: figure out a way to extract locality data from the gateway public endpoints in meshNetworks
+				util.AppendLbEndpointMetadata(&model.EndpointMetadata{
+					Network:   gw.Network,
+					TLSMode:   model.IstioMutualTLSModeLabel,
+					ClusterID: b.clusterID,
+					Labels:    labels.Instance{},
+				}, gwEp.Metadata)
+				// Currently gateway endpoint does not support tunnel.
+				lbEndpoints.append(gwIstioEp, gwEp)
 			}
-			// TODO: figure out a way to extract locality data from the gateway public endpoints in meshNetworks
-			util.AppendLbEndpointMetadata(&model.EndpointMetadata{
-				Network:   gw.Network,
-				TLSMode:   model.IstioMutualTLSModeLabel,
-				ClusterID: b.clusterID,
-				Labels:    labels.Instance{},
-			}, gwEp.Metadata)
-			// Currently gateway endpoint does not support tunnel.
-			lbEndpoints.append(gwIstioEp, gwEp)
 		}

 		// Endpoint members could be stripped or aggregated by network. Adjust weight value here.

This kinda works on the Istio side. However, i hit a roadblock from the envoy side :disappointed: Envoy deduplicates endpoints with the same address received from EDS: https://github.com/envoyproxy/envoy/issues/22417. Because of this, envoy throws away all endpoints with duplicate address of the east-west gateway except the first one in every cluster.
Here's /debug/edsz of my service using the patch. As you can see, there are two separate endpoints with different metadata for a single east-west gateway, because there are two pods in the remote cluster. This looks perfect in theory.
{
  "clusterName": "outbound|80||httpbin.***.svc.cluster.local",
  "endpoints": [
    {
      "locality": {
        "region": "$region1",
        "zone": "$zone1",
        "subZone": "$zone1-$rack1"
      },
      "lbEndpoints": [
        {
          "endpoint": {
            "address": {
              "socketAddress": {
                "address": "$pod_addr",
                "portValue": 80
              }
            }
          },
          "healthStatus": "HEALTHY",
          "metadata": {
            "filterMetadata": {
              "envoy.transport_socket_match": {
                "tlsMode": "istio"
              },
              "istio": {
                "workload": "httpbin;***;httpbin;0.0.0;$cluster1"
              }
            }
          },
          "loadBalancingWeight": 1
        }
      ],
      "loadBalancingWeight": 1
    },
    {
      "locality": {
        "region": "$region1",
        "zone": "$zone2",
        "subZone": "$zone2-$rack1"
      },
      "lbEndpoints": [
        {
          "endpoint": {
            "address": {
              "socketAddress": {
                "address": "$gw_address",
                "portValue": 15443
              }
            }
          },
          "metadata": {
            "filterMetadata": {
              "envoy.transport_socket_match": {
                "tlsMode": "istio"
              },
              "istio": {
                "workload": ";;;;$cluster1"
              }
            }
          },
          "loadBalancingWeight": 1
        }
      ],
      "loadBalancingWeight": 1
    },
    {
      "locality": {
        "region": "$region1",
        "zone": "$zone2",
        "subZone": "$zone2-$rack2"
      },
      "lbEndpoints": [
        {
          "endpoint": {
            "address": {
              "socketAddress": {
                "address": "$gw_address",
                "portValue": 15443
              }
            }
          },
          "metadata": {
            "filterMetadata": {
              "envoy.transport_socket_match": {
                "tlsMode": "istio"
              },
              "istio": {
                "workload": ";;;;$cluster1"
              }
            }
          },
          "loadBalancingWeight": 1
        }
      ],
      "loadBalancingWeight": 1
    }
  ]
},

However, here's endpoints dump from the envoy. As you can see, envoy just quietly dropped second endpoint.
$ istioctl pc endpoints -n *** httpbin-5df8f77f4f-z55l5 --cluster 'outbound|80||httpbin.***.svc.cluster.local' --output json
[
    {
        "name": "outbound|80||httpbin.***.svc.cluster.local",
        "addedViaApi": true,
        "hostStatuses": [
            {
                "address": {
                    "socketAddress": {
                        "address": "$pod_addr",
                        "portValue": 80
                    }
                },
                "stats": [
                    ...
                ],
                "healthStatus": {
                    "edsHealthStatus": "HEALTHY"
                },
                "weight": 1,
                "locality": {
                    "region": "$region1",
                    "zone": "$zone1",
                    "subZone": "$zone1-$rack1"
                }
            },
            {
                "address": {
                    "socketAddress": {
                        "address": "$gw_addr",
                        "portValue": 15443
                    }
                },
                "stats": [
                    ...
                ],
                "healthStatus": {
                    "edsHealthStatus": "HEALTHY"
                },
                "weight": 1,
                "locality": {
                    "region": "$region1",
                    "zone": "$zone2",
                    "subZone": "$zone2-$rack1"
                }
            }
        ],
        "circuitBreakers": {
            "thresholds": [
                ...
            ]
        },
        "observabilityName": "outbound|80||httpbin.***.svc.cluster.local",
        "edsServiceName": "outbound|80||httpbin.***.svc.cluster.local"
    }
]

This approach seems impossible to implement without that envoy issue being resolved. And judging by this comment https://github.com/envoyproxy/envoy/issues/22417#issuecomment-1353471480, it may not be a simple issue from envoy's point of view :disappointed:

I think we could implement this in Istio by apply the locality LB config then deduping. Instead of deduping then applying locality LB config

I think we could implement this in Istio by apply the locality LB config then deduping. Instead of deduping then applying locality LB config

I think this will only cover the simplest cases.
Let's say you have two k8s clusters inside one region.
Cluster A is in zone A. Zone A includes subzone A.
Cluster B is in zone B. Zone B includes subzones B and C.
Let's say you want to failover from cluster A to cluster B. Because of envoy limitation, you can only have a single endpoint for east-west gateway. That means you can't distinguish between subzones B and C, since single endpoint can't belong to both, only to neither. You can only use labels that are common for every workload, which is ok i guess.
But, the idea with separate endpoint for every label set combination is way cooler :slightly_smiling_face: Then you could use any set of labels for cross-network failover, not even just topology related ones. Like in the example in documentation for failoverPriority, you could use version label or anything else.

Does https://github.com/envoyproxy/envoy/issues/22417 apply even if the endpoint is in a different priority level?
What I was trying to express would allow 'the idea with separate endpoint for every label set combination is way cooler'.

Does https://github.com/envoyproxy/envoy/issues/22417 apply even if the endpoint is in a different priority level?

Just checked and yes it still applies. Even if the priority level is different only one endpoint remains.
Looking at the code it seems that only address field matters, in our case there are just address.socketAddress.address and address.socketAddress.portValue.

Just checked and yes it still applies. Even if the priority level is different only one endpoint remains.

To clarify, envoy keeps just the first endpoint from the list of "duplicates". Even if the following "duplicate" endpoints have numerically lower priority.

Is there any progress?
It seems that until this issue is resolved, the remote cluster cannot use multi-zone in Multi-Primary on different networks.


Actually I want to know openh264 supported resolution list to encode. Would you please provide me this information?

Openh264 should be consistent to the definitions on resolutions provided by the profile and level in Annex A. You may refer to the H.264/AVC Standard for more information.

I am very glad to get this reply, @huili2 .
I searched about H.264/AVC standard resolutions.. but haven't found any suitable answers. It's just said "Arbitrary resolution, not constrained to multiples of 16x16".
I have already tested some video files and I know that openh264 is able to encode or decode
176x144, 320x240, 352,288, 640x480 videos.
But, my concern is , I don't know whether openh264 is able to encode  videos with resolutions 50x52, 100x10, 15x21 , 521x211, 800x200 etc
Is there any other constraints about resolution? This answer will be very helpful for me.
Thanks in advance.

@RajibTheKing Ideally it is "arbitrary resolution" as you mentioned. However, there is max resolution constraint in each level, or more specifically, maxFS (max frame size in MB), e.g., Level 3.1 has maxFS 3600 (the size of 720p by accident).
Besides, openh264 encoder does not support encoding frame with frame width/height smaller than 16 (15x200, 14x14 are neither supported).
Btw:Although it is allowed in openh264 encoder to encode frame with odd size, from other viewpoints, I do not suggest you generate a frame with odd size in I420 format like 521x211.
So from your examples, 100x10, 15x21 are not supported while all others are OK.

I just tested video file with resolution 100x10 using H264. It's working fine. @huili2

@RajibTheKing are you sure you can encode this resolution using openh264 encoder? I tried just now, and was not able to on master branch.

@huili2 , Sorry I haven't used openh264, but I just used ffmpeg framework to encode or decode this video. FFmpeg contains -libx264 library. Maybe ffmpeg already modified to encode or decode any video files with arbitrary resolution except odd length.
I mean, 21x22 or 22x21 or 21x21 can't be processed using ffmpeg + libx264.
Finally, my observation is, [any width (even) x any height (even)] can be processed using ffmpeg + libx264.
I don't know openh264 is capable or not. If it's not capable we can modify openh264 to do this job. :)

@RajibTheKing Yes, that's why i agreed at very first that H.264 standard supports arbitrary resolution. Odd resolution is usually disabled because it is hard to convert odd width/height I420 format to RGB for display with the same result. You may learn more about I420 format then you may be able to get some info.
Openh264 does not support width/height < 16 just because it is not a usual case, and was designed by intention.

@huili2 , Thanks for your help. Resolution related information for openh264 is clear to me.

Firefox supports odd resolutions in OpenH264 IIRC - it's needed for various window-sharing cases and encoding a canvas.captureStream()


dockerize repo

will do after implementing Jim's code framework

Do you have a scope that you want dockerize here ?

@ngiangre I mean should we only containerize the Dash app itself or we need to include environment jupyter notebooks as well ?

Hmmm I would think both the notebooks and app would be a package deal. Do you have a suggestion here?
Cheers,
Nick
From: hsiao yi<EMAIL_ADDRESS>Reply-To: NCBI-Hackathons/SafeDrugs<EMAIL_ADDRESS>Date: Thursday, August 16, 2018 at 11:38 AM
To: NCBI-Hackathons/SafeDrugs<EMAIL_ADDRESS>Cc: Nick Giangreco<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [NCBI-Hackathons/SafeDrugs] dockerize repo (#11)
@ngiangre I mean should we only containerize the Dash app itself or we need to include environment jupyter notebooks as well ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I think we can have two separate docker containers for these two different parts. One for main Dash app and one for jupyter notebook. Eventually, all plots presented in jupyter notebooks would be moved integrated into  Dash app, right ?

Ideally, yes. That was the thought process initially. Have the notebooks be used by one audience, and the app used by an overlapping audience where the notebook code transfers “seamlessly” with the app’s code.
Cheers,
Nick
From: hsiao yi<EMAIL_ADDRESS>Reply-To: NCBI-Hackathons/SafeDrugs<EMAIL_ADDRESS>Date: Thursday, August 16, 2018 at 12:26 PM
To: NCBI-Hackathons/SafeDrugs<EMAIL_ADDRESS>Cc: Nick Giangreco<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [NCBI-Hackathons/SafeDrugs] dockerize repo (#11)
I think we can have two separate docker containers for these two different parts. One for main Dash app and one for jupyter notebook. Eventually, all plots presented in jupyter notebooks would be moved integrated into Dash app, right ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

The data is public and yes I'd want to put it in the public domain eventually


User reported that their current location is appended to image EXIF data by default

I recently received a complaint where a user believed that their current location was appended to the EXIF of their uploaded image without their consent. After doing a bit of digging to refresh my memory, it seems to me that this should not happen. As mentioned at https://github.com/commons-app/apps-android-commons/wiki/Category-suggestions-(readme) , the user's current location should only be collected and appended to the uploaded image (and used for category suggestions) if the user explicitly enables the setting for that. That is certainly the case for me when I test it.
Does this happen to anyone else?

Is it possible it was an image created using a different app with location info on it and then uploaded using this app?
If that is the case, maybe we should somehow detect it and show a warning about it.

It's hard to find out, as I wasn't given the user's contact or name, just contacted by the Wikimedia oversight team. :/ I think that as long as no one else has experienced this problem before, we can safely say that it isn't supposed to happen, and that if it happens again, we would like further details to try and isolate why that particular user is experiencing a problem?

My proposal https://phabricator.wikimedia.org/T143884 (for the Wikipedia app) went in this direction.
You cannot "replace" Panoramio because Panoramio's space is now taken by Google Maps and Google Photo, which trick users into submitting their own photos wherever they are for Google (and Google only) to use in its products. Google bought Panoramio and then gradually killed it, just like they removed the Wikimedia Commons layer from Google Maps at some point.
http://archiveteam.org/index.php?title=Panoramio
To attack Google's monopoly in this space you need users to understand that Google takes their rights away and that they have an alternative to do what they ostensibly care about (share and document certain places) while having some hope for visibility (thanks to copyleft and attribution). You need to send this message and provide this experience from some application they already find useful for other reasons (like OsmAnd, which added Mapillary, or the Wikipedia app).

@nemobis In your case the location EXIF won't be stripped. The complaint here was that the user's current location was appended to an image with no EXIF location data, without his permission. This should never happen. There is an option in Settings to use your current location as location data if the image has no EXIF data, but that is off by default and has to be enabled by the user if they want it.

Can we close this now, or is it still a problem?
Chris.


Add NSProgrammer to iOS Dev Blogs

Add NSProgrammer.com to the list of iOS Development Blogs

Just double checking, but the latest post to this blog is from 2013? If so, please add it to the Inactive section.

  Moved :)

I think the podcast is inactive now too? I'm not sure I want to start an inactive podcast section really. Is there value in cataloguing more blogs/podcasts that are years out of date? I'm not sure there is really.

Ah, sure, makes sense.  The podcast was topical so could be picked up like a reference but I see the value of keeping things curated to current stuff.  I’ll adjust.


Properly handle exact routing; fixes #39

Last patch is not working anymore... I'm going to review the tests and the integration before re-opening this PR.


[Task] Checklist before deploying v0.4.0

Task Description
Targeted Release Date: Nov 26, 2022
Here's a list of stuff that needs to be done before Kumiko v0.4.0 goes live. This list will be changed and new ones will get added later on

[ ] Audit all economy commands
[ ] Audit all additional commands (not from Rin)
[ ] Globally roll out all slash commands
[x] #158
[ ] #157
[x] Update Docs
[x] Fix unbanning user issue
[x] Add a global error handler for no permissions
[x] #160
[x] Rely on user perms and roles instead of bot perms for admin cmds
[x] #162
[x] #167
[x] #172
[x] Clean up code layout

oops made a mistake. should be #160 not #159

still in the process of fixing up bugs


Enhancement support add partitions in batch

Proposed changes
Issue Number: close #32524

run buildall

run buildall

run buildall

run buildall

run buildall

run buildall


HistoryViewer: explain "magic names"

GraphQL scaffolding uses names consisting of the first part of the namespace and the classname, but to inject it to the HistoryViewer field you need to use the database table name.
Took me hours to find out why the boilerplate doesn't work for me…

These docs are probably soon to become irrelevant I think? GraphQL 4 is changing how type names are resolved (I think). cc @unclecheese

ETA for graphql 4 being stable is unknown at this stage.  Also we may be doing '^3 || ^4' when requiring graphql as a dependency, so I think this is still worth merging.


add jasmine and some tests

Hi! I really like your plugin!
I wanted to contribute, so I added a few tests - hope you don't mind.
JS Police is a blog where we feature cool Open Source JavaScript libraries and do a little review, and then try to contribute what we find missing. For example, I noticed ReadRemaining didn't have tests, so I added some :)
Here's a link to the review: jspolice.com/review/readremaining
Cheers!

Hi @petarslovic! That's a great code review and we loved the JS Police initiative! Reading through code reviews is a great way to learn new things. Keep doing it!
Thanks for the tests as well, that was one of the biggest missing pieces of the library and we're more than happy to add them to the project.
Cheers!

Thanks! I really appreciate the feedback! 🍺


chore(deps): update dependency @types/node to v16.18.44

This PR contains the following updates:

Package
Type
Update
Change

@types/node (source)
devDependencies
patch
16.18.43 -> 16.18.44

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: yarn.lock
v18.17.1
[00:28:50.534] INFO (62): Installing tool node v18.17.1...
[00:28:50.540] INFO (62): tool already installed
    tool: "node"
9.6.7
0.18.0
[00:28:51.077] FATAL (62): EACCES: permission denied, scandir '/tmp/snap-private-tmp'
    err: {
      "type": "Error",
      "message": "EACCES: permission denied, scandir '/tmp/snap-private-tmp'",
      "stack":
          Error: EACCES: permission denied, scandir '/tmp/snap-private-tmp'
      "errno": -13,
      "code": "EACCES",
      "syscall": "scandir",
      "path": "/tmp/snap-private-tmp"
    }
[00:28:51.110] INFO (62): Installed tool node with errors in 576ms.


Amplify CLI Custom CDK - Cannot read properties of undefined (reading 'category')

How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
v16.16.0
Amplify CLI Version
12.2.4
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No manual changes made
Describe the bug
When building or pushing a custom resource CDK stack, get error Cannot read properties of undefined (reading 'category') when using basic example code.

Expected behavior
Expected to build successfully.
Reproduction steps

Run amplify add custom -> AWS CDK
In the generated AWS CDK code, uncomment the example on accessing other Amplify Resources:

    // Access other Amplify Resources
    const retVal:AmplifyDependentResourcesAttributes = AmplifyHelpers.addResourceDependency(this,
      amplifyResourceProps.category,
      amplifyResourceProps.resourceName,
      [
        {category: <insert-amplify-category>, resourceName: <insert-amplify-resourcename>},
      ]
    );

Insert a function that is in your resources. ie for me: { category: 'function', resourceName: 'fetchFlightsFn' }
Save file and run amplify push

Project Identifier
d7b341914af3ff80145ba75e9ea4eb36
Log output

# Put your logs below this line

2023-08-17T14:16:10.271Z|info : amplify push core
2023-08-17T14:16:10.312Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-17T14:16:14.406Z|info : amplify-provider-awscloudformation.zip-util.downloadZip.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip"},null])
2023-08-17T14:16:14.407Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:16:14.680Z|info : amplify-provider-awscloudformation.initialize-env.run.cfn.updateamplifyMetaFileWithStackOutputs([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:16:15.917Z|info : amplify-provider-awscloudformation.aws-cfn.updateamplifyMetaFileWithStackOutputs.cfn.listStackResources([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:16:16.129Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:16:16.255Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]tssearch-[***]1SFQMF/[***]6b10-[***]ee-[***]ee-[***]d8-[***]5a2d8"}])
2023-08-17T14:16:16.257Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]atssearch-[***]66OWT/[***]0cd0-[***]ee-[***]ee-[***]b8-[***]6f072"}])
2023-08-17T14:16:16.259Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ghtsVirginAu-[***]NEYSZX/[***]fbd0-[***]01-[***]ee-[***]3a-[***]35f72"}])
2023-08-17T14:16:16.387Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]ify-[***]json","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:16:31.476Z|error : There was an error building the custom resources
InvalidCustomResourceError: There was an error building the custom resources
2023-08-17T14:33:40.196Z|info : amplify push core
2023-08-17T14:33:40.238Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-17T14:33:44.473Z|info : amplify-provider-awscloudformation.zip-util.downloadZip.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip"},null])
2023-08-17T14:33:44.475Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:33:44.743Z|info : amplify-provider-awscloudformation.initialize-env.run.cfn.updateamplifyMetaFileWithStackOutputs([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:33:45.854Z|info : amplify-provider-awscloudformation.aws-cfn.updateamplifyMetaFileWithStackOutputs.cfn.listStackResources([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:33:46.011Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:33:46.134Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]tssearch-[***]1SFQMF/[***]6b10-[***]ee-[***]ee-[***]d8-[***]5a2d8"}])
2023-08-17T14:33:46.136Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]atssearch-[***]66OWT/[***]0cd0-[***]ee-[***]ee-[***]b8-[***]6f072"}])
2023-08-17T14:33:46.138Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ghtsVirginAu-[***]NEYSZX/[***]fbd0-[***]01-[***]ee-[***]3a-[***]35f72"}])
2023-08-17T14:33:46.270Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]ify-[***]json","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:34:00.887Z|error : There was an error building the custom resources
InvalidCustomResourceError: There was an error building the custom resources
2023-08-17T14:34:33.896Z|info : amplify push core
2023-08-17T14:34:33.939Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-17T14:34:37.442Z|info : amplify-provider-awscloudformation.zip-util.downloadZip.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip"},null])
2023-08-17T14:34:37.444Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:34:37.689Z|info : amplify-provider-awscloudformation.initialize-env.run.cfn.updateamplifyMetaFileWithStackOutputs([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:34:38.861Z|info : amplify-provider-awscloudformation.aws-cfn.updateamplifyMetaFileWithStackOutputs.cfn.listStackResources([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:34:39.034Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:34:39.162Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]tssearch-[***]1SFQMF/[***]6b10-[***]ee-[***]ee-[***]d8-[***]5a2d8"}])
2023-08-17T14:34:39.163Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]atssearch-[***]66OWT/[***]0cd0-[***]ee-[***]ee-[***]b8-[***]6f072"}])
2023-08-17T14:34:39.165Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ghtsVirginAu-[***]NEYSZX/[***]fbd0-[***]01-[***]ee-[***]3a-[***]35f72"}])
2023-08-17T14:34:39.302Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]ify-[***]json","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:34:50.668Z|error : There was an error building the custom resources
InvalidCustomResourceError: There was an error building the custom resources
2023-08-17T14:37:35.498Z|info : amplify version core  {"version":true,"yes":false}
2023-08-17T14:41:41.420Z|info : amplify push core
2023-08-17T14:41:41.471Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-17T14:41:45.486Z|info : amplify-provider-awscloudformation.zip-util.downloadZip.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip"},null])
2023-08-17T14:41:45.488Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:41:45.764Z|info : amplify-provider-awscloudformation.initialize-env.run.cfn.updateamplifyMetaFileWithStackOutputs([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:41:46.609Z|info : amplify-provider-awscloudformation.aws-cfn.updateamplifyMetaFileWithStackOutputs.cfn.listStackResources([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:41:46.770Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:41:46.897Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]tssearch-[***]1SFQMF/[***]6b10-[***]ee-[***]ee-[***]d8-[***]5a2d8"}])
2023-08-17T14:41:46.899Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]atssearch-[***]66OWT/[***]0cd0-[***]ee-[***]ee-[***]b8-[***]6f072"}])
2023-08-17T14:41:46.900Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ghtsVirginAu-[***]NEYSZX/[***]fbd0-[***]01-[***]ee-[***]3a-[***]35f72"}])
2023-08-17T14:41:47.033Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]ify-[***]json","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:42:02.024Z|error : There was an error building the custom resources
InvalidCustomResourceError: There was an error building the custom resources
2023-08-17T14:46:53.447Z|info : amplify push core
2023-08-17T14:46:53.491Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-17T14:46:57.719Z|info : amplify-provider-awscloudformation.zip-util.downloadZip.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip"},null])
2023-08-17T14:46:57.721Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:46:57.977Z|info : amplify-provider-awscloudformation.initialize-env.run.cfn.updateamplifyMetaFileWithStackOutputs([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:46:59.053Z|info : amplify-provider-awscloudformation.aws-cfn.updateamplifyMetaFileWithStackOutputs.cfn.listStackResources([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:46:59.210Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:46:59.334Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]tssearch-[***]1SFQMF/[***]6b10-[***]ee-[***]ee-[***]d8-[***]5a2d8"}])
2023-08-17T14:46:59.336Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]atssearch-[***]66OWT/[***]0cd0-[***]ee-[***]ee-[***]b8-[***]6f072"}])
2023-08-17T14:46:59.338Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ghtsVirginAu-[***]NEYSZX/[***]fbd0-[***]01-[***]ee-[***]3a-[***]35f72"}])
2023-08-17T14:46:59.468Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]ify-[***]json","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:47:14.699Z|error : There was an error building the custom resources
InvalidCustomResourceError: There was an error building the custom resources
2023-08-17T14:47:44.353Z|info : amplify remove custom
2023-08-17T14:47:44.391Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-17T14:48:00.216Z|info : amplify add custom
2023-08-17T14:48:00.256Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-17T14:49:20.897Z|info : amplify push core
2023-08-17T14:49:20.939Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-17T14:49:24.662Z|info : amplify-provider-awscloudformation.zip-util.downloadZip.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip"},null])
2023-08-17T14:49:24.664Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:49:24.951Z|info : amplify-provider-awscloudformation.initialize-env.run.cfn.updateamplifyMetaFileWithStackOutputs([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:49:26.104Z|info : amplify-provider-awscloudformation.aws-cfn.updateamplifyMetaFileWithStackOutputs.cfn.listStackResources([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:49:26.263Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:49:26.384Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]tssearch-[***]1SFQMF/[***]6b10-[***]ee-[***]ee-[***]d8-[***]5a2d8"}])
2023-08-17T14:49:26.385Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]atssearch-[***]66OWT/[***]0cd0-[***]ee-[***]ee-[***]b8-[***]6f072"}])
2023-08-17T14:49:26.387Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ghtsVirginAu-[***]NEYSZX/[***]fbd0-[***]01-[***]ee-[***]3a-[***]35f72"}])
2023-08-17T14:49:26.513Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]ify-[***]json","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:51:24.240Z|info : amplify push core
2023-08-17T14:51:24.284Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-17T14:51:27.449Z|info : amplify-provider-awscloudformation.zip-util.downloadZip.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip"},null])
2023-08-17T14:51:27.450Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:51:27.787Z|info : amplify-provider-awscloudformation.initialize-env.run.cfn.updateamplifyMetaFileWithStackOutputs([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:51:28.882Z|info : amplify-provider-awscloudformation.aws-cfn.updateamplifyMetaFileWithStackOutputs.cfn.listStackResources([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:51:29.051Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-17T14:51:29.177Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]tssearch-[***]1SFQMF/[***]6b10-[***]ee-[***]ee-[***]d8-[***]5a2d8"}])
2023-08-17T14:51:29.179Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]atssearch-[***]66OWT/[***]0cd0-[***]ee-[***]ee-[***]b8-[***]6f072"}])
2023-08-17T14:51:29.180Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ghtsVirginAu-[***]NEYSZX/[***]fbd0-[***]01-[***]ee-[***]3a-[***]35f72"}])
2023-08-17T14:51:29.321Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]ify-[***]json","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-17T14:51:40.403Z|error : There was an error building the custom resources
InvalidCustomResourceError: There was an error building the custom resources
2023-08-18T01:42:29.409Z|info : amplify build core
2023-08-18T01:42:29.455Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-18T01:44:10.492Z|info : amplify push core
2023-08-18T01:44:10.543Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-18T01:44:15.089Z|info : amplify-provider-awscloudformation.zip-util.downloadZip.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip"},null])
2023-08-18T01:44:15.091Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-18T01:44:15.376Z|info : amplify-provider-awscloudformation.initialize-env.run.cfn.updateamplifyMetaFileWithStackOutputs([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-18T01:44:16.688Z|info : amplify-provider-awscloudformation.aws-cfn.updateamplifyMetaFileWithStackOutputs.cfn.listStackResources([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-18T01:44:16.858Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-18T01:44:17.007Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]tssearch-[***]1SFQMF/[***]6b10-[***]ee-[***]ee-[***]d8-[***]5a2d8"}])
2023-08-18T01:44:17.009Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]atssearch-[***]66OWT/[***]0cd0-[***]ee-[***]ee-[***]b8-[***]6f072"}])
2023-08-18T01:44:17.011Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ghtsVirginAu-[***]NEYSZX/[***]fbd0-[***]01-[***]ee-[***]3a-[***]35f72"}])
2023-08-18T01:44:17.153Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]ify-[***]json","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-18T01:44:29.234Z|error : There was an error building the custom resources
InvalidCustomResourceError: There was an error building the custom resources
2023-08-18T01:46:10.191Z|info : amplify version core
2023-08-18T01:51:03.596Z|info : amplify diagnose core  {"send-report":true,"yes":false}
2023-08-18T01:51:03.643Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-18T02:01:39.993Z|info : amplify push core
2023-08-18T02:01:40.068Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}
2023-08-18T02:01:44.138Z|info : amplify-provider-awscloudformation.zip-util.downloadZip.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip"},null])
2023-08-18T02:01:44.140Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]rent-[***]ud-[***]d.zip","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-18T02:01:44.413Z|info : amplify-provider-awscloudformation.initialize-env.run.cfn.updateamplifyMetaFileWithStackOutputs([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-18T02:01:45.704Z|info : amplify-provider-awscloudformation.aws-cfn.updateamplifyMetaFileWithStackOutputs.cfn.listStackResources([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-18T02:01:45.883Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]ify-[***]8b158cb4-[***]ing-[***]556"}])
2023-08-18T02:01:46.014Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]tssearch-[***]1SFQMF/[***]6b10-[***]ee-[***]ee-[***]d8-[***]5a2d8"}])
2023-08-18T02:01:46.015Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]atssearch-[***]66OWT/[***]0cd0-[***]ee-[***]ee-[***]b8-[***]6f072"}])
2023-08-18T02:01:46.017Z|info : amplify-provider-awscloudformation.aws-cfn.describeStack.cfn.describeStacks([{"StackName":"[***]rmation:ap-[***]east-[***]53:stack/[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ghtsVirginAu-[***]NEYSZX/[***]fbd0-[***]01-[***]ee-[***]3a-[***]35f72"}])
2023-08-18T02:01:46.144Z|info : amplify-provider-awscloudformation.aws-s3.s3.getFile([{"Key":"[***]ify-[***]json","Bucket":"[***]ify-[***]8b158cb4-[***]ing-[***]556-[***]ment"}])
2023-08-18T02:02:00.647Z|error : There was an error building the custom resources
InvalidCustomResourceError: There was an error building the custom resources
2023-08-18T02:02:08.182Z|info : amplify build core
2023-08-18T02:02:08.223Z|info : @aws-amplify/amplify-cli-core.banner-message/index.ts.fetch banner messages from https://aws-amplify.github.io/amplify-cli/banner-message.json({}

Additional information
I think this is very similar to https://github.com/aws-amplify/amplify-cli/issues/13122.
There the suggested fix is to use specific versions. My versions in amplify/backend/custom/customResource7f1c64f3/package.json
{
  "name": "custom-resource",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "@aws-amplify/cli-extensibility-helper": "^3.0.14",
    "aws-cdk-lib": "~2.80.0",
    "constructs": "^10.2.69"
  },
  "devDependencies": {
    "typescript": "^5.1.6"
  }
}

I have set them the same as the other issue suggests but still encounter the issue.
Is there a build/install step that needs to be performed when editing this? Or is running amplify build / amplify push the correct steps?
Related Eslint issue
Also when I enable TS eslint linting on the file (amplify/backend/custom/customResource7f1c64f3/cdk-stack.ts) including the rule @typescript-eslint/prefer-nullish-coalescing and enable "strictNullChecks": true in tsconfig.json, I get warnings that 'amplifyResourceProps' is possibly 'undefined'.. Which is interestingly related to the console error :Cannot read properties of undefined (reading 'category')

So I then made amplifyResourceProps non-nullable (remove the ?) which makes the eslint error go away.

However after this the error still exists on amplify push.
I have been battling with this for days and tried many examples online only to be blocked by this issue over and over again. 😢
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

I have been using this as a guide, still with the error: https://github.com/aws-samples/amplify-cdkv2-stepfunctions

Hey @samturner3, thank you for reaching out, I was able to reproduce the issue. We are currently looking into a workaround, tried removing the node modules ,yarn.lock and then build which did not mitigate the issue.
Reproduction steps:

amplify add custom
which created the following package.json

{
  "name": "custom-resource",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "@aws-amplify/cli-extensibility-helper": "^3.0.0",
    "aws-cdk-lib": "~2.80.0",
    "constructs": "^10.0.5"
  },
  "devDependencies": {
    "typescript": "^4.9.5"
  }
}

replace with the following

{
  "name": "custom-resource",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "@aws-amplify/cli-extensibility-helper": "^3.0.0",
    "aws-cdk-lib": "~2.92.0",
    "constructs": "^10.2.69"
  },
  "devDependencies": {
    "typescript": "^5.1.6"
  }
}

run amplify build and observe error. Also changed the "@aws-amplify/cli-extensibility-helper": "^3.0.14" which did not mitigate it.

however, removing the custom resource entirely amplify remove custom, then amplify add custom and modify the package.json with
{
  "name": "custom-resource",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "@aws-amplify/cli-extensibility-helper": "^3.0.14",
    "aws-cdk-lib": "~2.80.0",
    "constructs": "^10.2.69"
  },
  "devDependencies": {
    "typescript": "^5.1.6"
  }
}

running build did not throw any errors

@samturner3 noticed some additional information. Does the custom resource folder have a tsconfig.json file similar to following.
{
  "compilerOptions": {
    "target": "es6",
    "module": "commonjs",
    "strict": false,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "build"
  }
}

if not, could you create file with the above and build the project amplify build?

@samturner3 noticed some additional information. Does the custom resource folder have a tsconfig.json file similar to following.
{
  "compilerOptions": {
    "target": "es6",
    "module": "commonjs",
    "strict": false,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "build"
  }
}

if not, could you create file with the above contents and build the project amplify build?

I followed your instructions (amplify remove custom, then amplify add custom and modify the package.json), and now builds.
Yes It does have a tsconfig.json with those contents.
I'll continue restoring my code and see if I run into any more issues.

This error is again popping up with the correct package.json config.
I really don't want to remove and add my custom component everytime this happens, especially when in production. What is fix here?

Hey @samturner3, could you provide us the output by running amplify push --debug?
Additionally, I was able to reproduce the issue by adding the @typescript-eslint/prefer-nullish-coalescing and "strictNullChecks": true in tsconfig.json.
Could you try removing the options and run amplify build --debug and observe if the undefined error does not appears in cdk-stack.ts?

I am hesitant to do any more testing on my project as it seems to be working ok now.
From memory yes adding the tsconfig and eslint rules made it pop up again. I have removed / disabled these rules for now on my project.

I understand, please feel in reaching out to us again if you need any further assistance.
Closing the issue.


Allow api.radar.io requests

Radar is a legit business that serves up map tiles.

See https://news.ycombinator.com/item?id=37669290

Thank you for this Patrick @pcl.
Do you work for Radar?

Patrick @pcl I appreciate this pull request but, based on the evidence I see, I decline.
Closing.

I don’t.
FYI, according to their privacy FAQ, location tracking is end-user opt-in. However, looking at their privacy policy, the policy claims end-user opt-out.
https://radar.com/trust
https://radar.com/privacy
Also, unrelatedly — I noticed that some of your hosts files sent the address to <IP_ADDRESS> and some to <IP_ADDRESS>. I didn’t investigate further to see if you had a reason for the inconsistency.

Hi Patrick @pcl all our hosts variants use <IP_ADDRESS> by default except in a few records at top of file.
That section is verbatim, a unified and de-duplicated collection of entries from OEM hosts files, sourced from a wide variety of operating systems.
Decided not to modify those because hosts files long predate the internet as we know it, and lord knows what scripts exist in userland that may parse hosts files for unimaginable reasons.  So the decision was, let's not gratuitously mess with those.
Note that we provide an --ip flag for people who want to generate something other than our default <IP_ADDRESS> mapping.

Hello, can this be revisisted? I've had users dissatisfied because this unexpectedly broke part of our web app.
I think there are a couple things worth clarifying:

Radar is opt-in. Users must explicitly grant geolocation permissions (browser or OS level) or manually enter their own address before Radar can record it. AFAIK, Radar's "tracking" merely is just saving these user-provided coordinates and device IP to their backend, which is pretty similar to the website/app just using a different mapping provider and saving them to its own backend.
Radar is for first-party location use cases, think like a DoorDash-style delivery app that needs realtime location, or a dating app that asks users for their location to show nearby people. Importantly, again, these are things the user already must opt into at the platform level