Honda Accord 2020 Not Working ACC/LKAS/RDM Dashboard Error

Describe the bug
Recently switched over from a Comma 2 which was running the stock version of OpenPIlot perfectly fine and without issue. When using Comma 3 with stock (release3) OpenPilot software on a non-hybrid Honda Accord 2020 the vehicle dashboard displays an ACC, LKAS, and RDM error. During this time, OpenPilot does not display any errors but does not appear to receive or respond to any of the cruise control commands from the vehicle. With the vehicle's cruise main turned on the ACC, LKAS, Honda sensing icon, and the info icon are all red. Clicking on the cruise +/- steering wheel buttons make an audible error sound and nothing happens on the OpenPilot display. This problem can be reproduced once OpenPilot loads and switches the harness box relay to use the Comma 3.
The harness, harness box, and all cables have already been reconnected and even replaced to ensure that the issue is not due to a faulty connection. I suspect this is software related specifically with my vehicle year since, during testing, switching to the master branch and enabling experimental mode does not yield any errors on either the Comma 3 or the vehicle and everything works as it should.
I would really like to get the release version working for me since I prefer using the vehicle's ACC for now. Any help is appreciated!
Which car does this affect?
Honda Accord 2020
Provide a route where the issue occurs
7c21724ca42488d4|2022-11-28--13-01-01--13
openpilot version
0.9.0
Additional info
Not sure if any of these errorLogMessage errors mean anything, but here are some from another drive 7c21724ca42488d4|2022-12-09--19-52-12--1
{'errorLogMessage': '{"created":<PHONE_NUMBER>.1287196, "ctx": {"daemon": "modeld", "device": "tici", "dirty": false, "dongle_id": "7c21724ca42488d4", '
'"version": "0.9.0-release"}, "filename": "selfdrive/modeld/modeld.cc", "funcname": "run_model", "levelnum": 40, "lineno": 90, '
'"msg": "vipc_client_main no frame"}',
'logMonoTime':<PHONE_NUMBER>61,
'valid': True}
{'errorLogMessage': '{"created":<PHONE_NUMBER>.1662509, "ctx": {"daemon": "modeld", "device": "tici", "dirty": false, "dongle_id": "7c21724ca42488d4", '
'"version": "0.9.0-release"}, "filename": "selfdrive/modeld/modeld.cc", "funcname": "run_model", "levelnum": 40, "lineno": 150, '
'"msg": "skipping model eval. Dropped -1 frames"}',
'logMonoTime':<PHONE_NUMBER>27,
'valid': True}
{'errorLogMessage': '{"msg": {"event": "fingerprinted", "car_fingerprint": "HONDA ACCORD 2018", "source": 1, "fuzzy": false, "cached": false, '
'"fw_count": 13, "ecu_responses": [[417001776, null, 1], [417001967, null, 1], [417001744, null, 1], [417001786, null, 1], '
'[417001904, null, 1], [417001758, null, 1], [417001768, null, 1], [417001771, null, 1], [417001825, null, 1], [417001739, null, '
'1], [417001811, null, 1], [417001824, null, 1], [417001909, null, 1]], "vin_rx_addr": 417001744, "error": true}, "ctx": '
'{"daemon": "controlsd", "dongle_id": "7c21724ca42488d4", "version": "0.9.0-release", "dirty": false, "device": "tici"}, '
'"level": "ERROR", "levelnum": 40, "name": "swaglog", "filename": "car_helpers.py", "lineno": 171, "pathname": '
'"/data/openpilot/selfdrive/car/car_helpers.py", "module": "car_helpers", "funcName": "fingerprint", "host": "tici", "process": '
'46572, "thread":<PHONE_NUMBER>56, "threadName": "MainThread", "created":<PHONE_NUMBER>.7578797}',
'logMonoTime':<PHONE_NUMBER>68,
'valid': True}
{'errorLogMessage': '{"created":<PHONE_NUMBER>.3671598, "ctx": {"daemon": "locationd", "device": "tici", "dirty": false, "dongle_id": '
'"7c21724ca42488d4", "version": "0.9.0-release"}, "filename": "selfdrive/locationd/locationd.cc", "funcname": "handle_gps", '
'"levelnum": 40, "lineno": 343, "msg": "Locationd vs ubloxLocation position difference too large, kalman reset"}',
'logMonoTime':<PHONE_NUMBER>58,
'valid': True}

Hi @joseption, is this still an issue for you?

Any updates @joseption?

It looks like you returned your device, so I'm going to close this. In the original route you sent, panda was reporting issues sending messages to the camera (likely all the messages it should have been forwarding), which would explain why everything was fine when using openpilot longitudinal, as we were blocking the camera's messages displaying faults.
Likely hardware issue, either panda or the OBD-C cable connected to the comma three.


dracut: remove link-local addr from network config

This is screwing with EC2's networking.

Fixes https://github.com/coreos/ignition/issues/118.

LGTM


Add experimental x64 context manager

This is an experiment in allowing the X64 flag to be temporarily set via a context manager. For example:
import numpy as np
import jax.numpy as jnp
from jax import config, jit

from jax.experimental import enable_x64, disable_x64

# Works with and without experimental_cpp_jit
# config.update('experimental_cpp_jit', False)
config.update('jax_enable_x64', False)

x = np.random.randn(100, 100)

print(jnp.array(x).dtype)
# float32

u, s, vt = jnp.linalg.svd(x)
print(u.dtype)
# float32

j_svd = jit(jnp.linalg.svd)

u, s, vt = j_svd(x)
print(u.dtype)
# float32

with enable_x64():
    print(jnp.array(x).dtype)
    # float64

    u, s, vt = jnp.linalg.svd(x)
    print(u.dtype)
    # float64

    with disable_x64(): # Nested context managers!
        print(jnp.array(x).dtype)
        # float32

    u, s, vt = j_svd(x)
    print(u.dtype)
    # float64

~I think the CPP jit cache is the one big remaining issue, though there may be others. I'm curious to hear thoughts about this approach!~
Small change made it so this works even with CPP jit (thanks @mattjj!)
Update: added some simple CI tests.

Awesome!
I'm not sure yet but I think we might need to update the util.cache decorator too, like the way util.memoize was updated. Those are used, for example, on lax control flow, caching the jaxprs that get formed. We don't want to reuse jaxprs that were cached with x64=False if we now have x64=True.
Maybe we could:

instead of adding a new separate memoize_x64, change the existing util.cache and util.memoize (and linear_util.cache) always to be sensitive to the x64 flag status
have an eye towards making this generalizable, in case we need to make the caches sensitive to other context (I'm working on a leak-checker flag with @jekbradbury right now which would need this!)

WDYT?

Awesome!
I'm not sure yet but I think we might need to update the util.cache decorator too, like the way util.memoize was updated. Those are used, for example, on lax control flow, caching the jaxprs that get formed. We don't want to reuse jaxprs that were cached with x64=False if we now have x64=True.
Maybe we could:

instead of adding a new separate memoize_x64, change the existing util.cache and util.memoize (and linear_util.cache) always to be sensitive to the x64 flag status
have an eye towards making this generalizable, in case we need to make the caches sensitive to other context (I'm working on a leak-checker flag with @jekbradbury right now which would need this!)

WDYT?

I initially made memoize itself sensitive to the flag status, but off the bat that led to the WARNING:absl:No GPU/TPU found, falling back to CPU. warning being printed twice.
I'll take a look at util.cache and add a control flow test.

I initially made memoize itself sensitive to the flag status, but off the bat that led to the WARNING:absl:No GPU/TPU found, falling back to CPU. warning being printed twice.
I'll take a look at util.cache and add a control flow test.

I initially made memoize itself sensitive to the flag status, but off the bat that led to the WARNING:absl:No GPU/TPU found, falling back to CPU. warning being printed twice.

Printing a warning twice doesn't seem too bad :P
I guess there are only two only callers of util.memoize, in dtypes.py and in xla_bridge.py. Still, it might make sense for the "default" function util.memoize to have the right context sensitivity, and for the get_backend function in xla_bridge.py to opt out of that sensitivity (just by calling functools.lru_cache(maxsize=None) directly; we don't really need an alias for that).

I initially made memoize itself sensitive to the flag status, but off the bat that led to the WARNING:absl:No GPU/TPU found, falling back to CPU. warning being printed twice.

Printing a warning twice doesn't seem too bad :P
I guess there are only two only callers of util.memoize, in dtypes.py and in xla_bridge.py. Still, it might make sense for the "default" function util.memoize to have the right context sensitivity, and for the get_backend function in xla_bridge.py to opt out of that sensitivity (just by calling functools.lru_cache(maxsize=None) directly; we don't really need an alias for that).


feat(client): remove the bootstrap grid component entirely

After ahmad find the issue, we can import the container to codebase and remove the grid component entirely

You could include this to the current pr.

I don't think so. It is not as straightforward.

I don't think so. It is not as straightforward.

there is inline CSS that should be changed to tailwind, so I am adding container to blocked for now, and going to move the deleting the grid into its own PR.


FkProducer.java:41: Fake send is not implemented

The puzzle 44-72db5d02 from #44 has to be resolved:
https://github.com/eo-cqrs/eo-kafka/blob/d78f949e67ac72229c396ec402568cb6573b91c9/src/main/java/io/github/eocqrs/kafka/fake/FkProducer.java#L41-L41
The puzzle was created by h1alexbel on 04-May-23.
Estimate: 60 minutes,  role: DEV.
If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

@0pdd thank you for reporting this. I'll assign someone to take care of it soon.

@h1alexbel this is your task now, please go ahead. Deadline (when this ticket should be closed) is 2023-05-14T12:12:27.217680.
Estimation here is 60 minutes, that's how much you will be paid.
Remember, you don't have to solve everything in this ticket - you can solve it partially and leave todo markers in the code, which will become future tasks.
If you have any questions don't ask me, I'm not a technical person. Open new tickets instead.
If you don't have time or simply don't want to work on this, you can always resign.

@h1alexbel Don't forget to close this ticket before the deadline (2023-05-14T12:12:27). You are past the first half of the allowed period.

@zoeself deregister

@l3r8yJ depends on #120

@0pdd the puzzle #364 is still not solved.

@0pdd the only puzzle #364 is solved here.


Fix setting of DDEVIC.

Even though there are no multiple drives, this code was wrong.
Regards,
Ivo

Merged --- thanks!


Multiple roots in the archive

We don't need this, because you can create an IPFS object linking out to whatever your multiple roots would have been.  So instead of:
$ ipfs export <ip*s-path-1> <ip*s-path-2> … > archive

you can do:
$ ipfs object put --link my-first-path=<ip*s-path-1> --link my-second-path=<ip*s-path-2>
<root-object-hash>
$ ipfs export /ipfs/<root-object-hash> > archive

Of course, ipfs object put doesn't take --link <name>=<ip*s-path> options yet, but that's a separate problem ;).

Previous discussion in ipfs/go-ipfs#1195.


[pubsub] puller requires more permissions than it should for acker

So I decide to create a service account with absolutely no IAM roles defined, and then I added the Pub/Sub Subscriber permission to some subscription, which fails to authorize with google-cloud-go when I call subscription.Pull. If I add the Pub/Sub Viewer permission then, all of a sudden, it starts working.
This left me wondering because google-cloud-java works with just the Subscriber permission.
At close inspection, I noticed Pull is trying to get the subscription configuration (so requiring the Viewer permission would make sense).
https://github.com/GoogleCloudPlatform/google-cloud-go/blob/3c4c8cc11d151d76587802cb55dd7b80beca832b/pubsub/subscription.go#L141
But then, I wondered how were the java guys doing it, which seems to be like this.
https://github.com/GoogleCloudPlatform/google-cloud-java/blob/0a5a27f067ee4b649148ea90974b6536a7f5b671/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/AckDeadlineRenewer.java#L191
So apparently they are not requesting the subscription's config for getting the ack deadline option, but rather fetching messages and acking with a delay that depends on the current message's expected ack deadline (which looks smarter, albeit more complex).
I am writing this issue to first ask you if you were aware of this and/or if this is a design decision. Secondly, if you were OK with accepting a PR that would remove the retrieval of the subcription's config and use the next message's expected ack deadline, similar to what the java client does?

The Java StreamingPull implementation records the message-acking latency in a distribution. It periodically sets the message deadline to the 99th percentile. We can do the same in here and it will naturally make the viewer permission unnecessary.
I'll prioritize this at P2 since the current implementation still works if you're OK with the additional role.

Same here. Lost all the day fighting against this as well.

Same here, unable to make it work until I realised that editor worked...and finally discovered that an issue was already filed.


Error while running fedifetcher: "Error getting user ID" on certain URLs and "KeyError: 'url'"

Hello!
Lately I have observed the following errors while running fedifetcher:
The URLs it complains work for me in the browser.
2023-04-29 19:30:52.973901 CEST: Error parsing toot URL https://digitalcourage.video/videos/watch/80110bb9-2048-44cc-8a77-0f0b42da900e
2023-04-29 19:30:54.483262 CEST: Error parsing toot URL https://digitalcourage.video/videos/watch/d6a27ca1-9fde-4821-9b8a-ae25c8515609
2023-04-29 19:30:59.137947 CEST: Error getting context for toot None. Status code: 401
2023-04-29 19:32:11.349357 CEST: Error parsing toot URL https://anonsys.net/display/bf69967c-6664-495d-6e3a-a16077737418
2023-04-29 19:32:56.704193 CEST: Error getting user ID for user<EMAIL_ADDRESS>User digitalcourage.de was not found on server digitalcourage.video/accounts.
2023-04-29 19:32:56.858679 CEST: Error getting user ID for user<EMAIL_ADDRESS>User bba was not found on server digitalcourage.video/video-channels.
2023-04-29 19:32:56.995373 CEST: Error getting user ID for user<EMAIL_ADDRESS>User digitalcourage.de was not found on server digitalcourage.video/accounts.
2023-04-29 19:32:57.550275 CEST: Error getting user ID for user<EMAIL_ADDRESS>Error getting URL https://types.pl/api/v1/accounts/lookup?acct=amy. Status code: 401
2023-04-29 19:32:58.050662 CEST: Error getting user ID for user<EMAIL_ADDRESS>Expecting value: line 1 column 1 (char 0)
2023-04-29 19:32:58.311605 CEST: Error getting user ID for user<EMAIL_ADDRESS>Expecting value: line 1 column 1 (char 0)
2023-04-29 19:50:20.165598 CEST: Job failed after 0:02:20.695650.
Traceback (most recent call last):
  File "/app/find_posts.py", line 878, in <module>
    add_user_posts(arguments.server, token, filter_known_users(mentioned_users, all_known_users), recently_checked_users, all_known_users, seen_urls)
  File "/app/find_posts.py", line 75, in add_user_posts
    if post['reblog'] == None and post['url'] != None and post['url'] not in seen_urls:
                                  ~~~~^^^^^^^
KeyError: 'url'

Could you take a look?
Thanks as always for your work!

Hi @b2cc
thanks for that. The 'Error parsing toot URL', 'Error getting context for toot None', and 'Error getting user ID' errors are all because these are toots / users from unsupported software such as peer tube.
I'd be happy to accept PRs that implement support for further software, but at the moment these toots and users are simply skipped.
This is more unexpected though:

2023-04-29 19:50:20.165598 CEST: Job failed after 0:02:20.695650.

I do feel that there is crucial information missing though. Are you able to upload a full log, please? I can then look into it

Hi,
I understand, then let's ignore the peertube errors.
Here is a failed log from a current run:
2023-04-30 14:45:10.224214 CEST: Starting FediFetcher
2023-04-30 14:45:12.210999 CEST: Found active user: esperantocollective_vienna
2023-04-30 14:45:12.842749 CEST: Found active user: roland_w
2023-04-30 14:45:13.407944 CEST: Found active user: gunklbot
2023-04-30 14:45:14.222352 CEST: Found 0 reply toots
2023-04-30 14:45:14.222447 CEST: Found 0 known context toots
2023-04-30 14:45:14.222534 CEST: Added 0 new context toots (with 0 failures)
2023-04-30 14:45:25.230835 CEST: Found 260 toots in timeline
2023-04-30 14:45:25.535041 CEST: Got context for toot None
2023-04-30 14:45:25.824994 CEST: Got context for toot None
2023-04-30 14:45:26.006872 CEST: Got context for toot None
2023-04-30 14:45:26.236387 CEST: Got context for toot https://hachyderm.io/@Martindotnet/110287584615058310
2023-04-30 14:45:26.515591 CEST: Got context for toot None
2023-04-30 14:45:26.673573 CEST: Got context for toot https://aut.social/@bernhard/110287413319610987
2023-04-30 14:45:26.875856 CEST: Got context for toot https://die-partei.social/@rockpapershotgun/110287297074604228
2023-04-30 14:45:27.092613 CEST: Got context for toot https://mastodon.social/@lenzgr/110287267707069042
2023-04-30 14:45:27.765308 CEST: Got context for toot None
2023-04-30 14:45:28.299109 CEST: Got context for toot None
2023-04-30 14:45:28.656461 CEST: Got context for toot None
2023-04-30 14:45:28.914532 CEST: Got context for toot None
2023-04-30 14:45:29.161544 CEST: Got context for toot None
2023-04-30 14:45:29.393401 CEST: Got context for toot None
2023-04-30 14:45:29.616969 CEST: Got context for toot None
2023-04-30 14:45:29.879347 CEST: Got context for toot None
2023-04-30 14:45:30.134010 CEST: Got context for toot None
2023-04-30 14:45:30.303378 CEST: Got context for toot None
2023-04-30 14:45:30.693247 CEST: Got context for toot https://cloud-native.social/@saiyam/110287136504862220
2023-04-30 14:45:30.869777 CEST: Got context for toot https://hachyderm.io/@zatomas/110287029126645805
2023-04-30 14:45:30.986809 CEST: Got context for toot https://aut.social/@bernhard/110286907898220214
2023-04-30 14:45:31.815068 CEST: Discovered redirect for URL https://social.kernel.org/objects/a12b8afa-e6d4-4728-a883-29e27bfe1515
2023-04-30 14:45:32.630134 CEST: Got context for toot None
2023-04-30 14:45:33.178963 CEST: Got context for toot None
2023-04-30 14:45:33.352700 CEST: Got context for toot None
2023-04-30 14:45:33.576993 CEST: Got context for toot https://infosec.exchange/@letsencrypt/110284856209495778
2023-04-30 14:45:33.761074 CEST: Got context for toot https://mastodon.social/@effinbirds/110284851305168069
2023-04-30 14:45:33.926131 CEST: Got context for toot https://die-partei.social/@rockpapershotgun/110284289013744298
2023-04-30 14:45:34.228388 CEST: Got context for toot https://mastodon.social/@effinbirds/110284001984000301
2023-04-30 14:45:35.019812 CEST: Got context for toot None
2023-04-30 14:45:35.218117 CEST: Got context for toot https://mastodon.social/@effinbirds/110283219579638181
2023-04-30 14:45:35.488838 CEST: Got context for toot None
2023-04-30 14:45:35.952581 CEST: Got context for toot https://mstdn.social/@feditips/110282867010964061
2023-04-30 14:45:36.115800 CEST: Got context for toot https://mstdn.social/@tanweerdar/110282833666725775
2023-04-30 14:45:36.423547 CEST: Got context for toot None
2023-04-30 14:45:36.623051 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110282720076702784
2023-04-30 14:45:36.861597 CEST: Got context for toot https://social.tchncs.de/@kuketzblog/110282653403169476
2023-04-30 14:45:37.146303 CEST: Got context for toot None
2023-04-30 14:45:37.146934 CEST: Error parsing toot URL https://digitalcourage.video/videos/watch/80110bb9-2048-44cc-8a77-0f0b42da900e
2023-04-30 14:45:37.358651 CEST: Got context for toot https://mastodon.social/@effinbirds/110282492031152082
2023-04-30 14:45:37.594456 CEST: Got context for toot None
2023-04-30 14:45:38.198146 CEST: Got context for toot None
2023-04-30 14:45:38.439423 CEST: Got context for toot https://fosstodon.org/@kernellogger/110282350145400526
2023-04-30 14:45:38.687111 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110282030390617805
2023-04-30 14:45:38.687472 CEST: Error parsing toot URL https://digitalcourage.video/videos/watch/d6a27ca1-9fde-4821-9b8a-ae25c8515609
2023-04-30 14:45:38.942176 CEST: Got context for toot https://ublog.tech/@IPngNetworks/110281893500422871
2023-04-30 14:45:39.118184 CEST: Got context for toot https://mastodon.derstandard.at/@web/110281536462189131
2023-04-30 14:45:39.553859 CEST: Got context for toot None
2023-04-30 14:45:39.768080 CEST: Got context for toot https://mastodon.social/@nicorola/110281446310399347
2023-04-30 14:45:39.988256 CEST: Got context for toot https://mas.to/@marcopogo/110281438099694447
2023-04-30 14:45:40.125731 CEST: Got context for toot https://aut.social/@bernhard/110281417844848973
2023-04-30 14:45:40.315102 CEST: Got context for toot https://die-partei.social/@rockpapershotgun/110281025295534594
2023-04-30 14:45:40.618086 CEST: Got context for toot None
2023-04-30 14:45:40.896360 CEST: Got context for toot None
2023-04-30 14:45:41.050583 CEST: Got context for toot https://chaos.social/@epicenter_works/110280985990730388
2023-04-30 14:45:41.231799 CEST: Got context for toot https://mastodon.social/@nicorola/110280812555397064
2023-04-30 14:45:41.440239 CEST: Got context for toot https://hachyderm.io/@molly0xfff/110280728782230553
2023-04-30 14:45:41.840453 CEST: Got context for toot None
2023-04-30 14:45:42.064359 CEST: Got context for toot https://social.opendesktop.org/@thisweekinkde/110280415916402820
2023-04-30 14:45:42.399262 CEST: Got context for toot https://hachyderm.io/@volkan/110280154384709385
2023-04-30 14:45:43.176930 CEST: Got context for toot None
2023-04-30 14:45:43.733392 CEST: Error getting context for toot None. Status code: 401
2023-04-30 14:45:44.690163 CEST: Got context for toot None
2023-04-30 14:45:45.724906 CEST: Got context for toot https://aus.social/@dgar/110279274329093158
2023-04-30 14:45:45.967176 CEST: Got context for toot https://mastodon.social/@effinbirds/110279189011064254
2023-04-30 14:45:46.356107 CEST: Got context for toot https://mastodon.social/@KydiaMusic/110279017066632838
2023-04-30 14:45:46.878857 CEST: Got context for toot None
2023-04-30 14:45:47.079018 CEST: Got context for toot https://mastodon.xyz/@xkcd/110278690633039540
2023-04-30 14:45:47.451374 CEST: Got context for toot None
2023-04-30 14:45:48.857660 CEST: Got context for toot None
2023-04-30 14:45:49.849319 CEST: Got context for toot None
2023-04-30 14:45:50.303190 CEST: Got context for toot None
2023-04-30 14:45:50.836012 CEST: Got context for toot None
2023-04-30 14:45:51.106391 CEST: Got context for toot None
2023-04-30 14:45:51.476231 CEST: Got context for toot None
2023-04-30 14:45:51.743183 CEST: Got context for toot None
2023-04-30 14:45:51.975188 CEST: Got context for toot None
2023-04-30 14:45:52.782476 CEST: Got context for toot None
2023-04-30 14:45:53.180889 CEST: Got context for toot None
2023-04-30 14:45:53.349333 CEST: Got context for toot None
2023-04-30 14:45:54.194180 CEST: Got context for toot https://social.tchncs.de/@kuketzblog/110278235794716210
2023-04-30 14:45:54.415474 CEST: Got context for toot https://mastodon.social/@effinbirds/110278111612141534
2023-04-30 14:45:55.374264 CEST: Got context for toot None
2023-04-30 14:45:55.609112 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277834076718028
2023-04-30 14:45:56.120584 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277817823007086
2023-04-30 14:45:56.338411 CEST: Got context for toot None
2023-04-30 14:45:56.657654 CEST: Got context for toot None
2023-04-30 14:45:57.184152 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277760031436221
2023-04-30 14:45:57.570756 CEST: Got context for toot None
2023-04-30 14:45:57.762183 CEST: Got context for toot https://mastodon.social/@sjvn/110277742968854135
2023-04-30 14:45:58.015609 CEST: Got context for toot https://aut.social/@bernhard/110277732860325420
2023-04-30 14:45:58.190438 CEST: Got context for toot None
2023-04-30 14:45:58.379660 CEST: Got context for toot https://social.tchncs.de/@random_musings/110277730784037217
2023-04-30 14:45:58.919294 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277728697557991
2023-04-30 14:45:59.424557 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277710154148747
2023-04-30 14:45:59.934852 CEST: Got context for toot None
2023-04-30 14:46:00.147151 CEST: Got context for toot None
2023-04-30 14:46:00.382848 CEST: Got context for toot None
2023-04-30 14:46:00.769411 CEST: Got context for toot https://ublog.tech/@IPngNetworks/110277679390282774
2023-04-30 14:46:01.155468 CEST: Got context for toot https://ublog.tech/@IPngNetworks/110277667478587903
2023-04-30 14:46:01.682433 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277660931499636
2023-04-30 14:46:01.868417 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277648006143960
2023-04-30 14:46:02.179747 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277642786072636
2023-04-30 14:46:02.460889 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277620605502755
2023-04-30 14:46:02.860692 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277618831175533
2023-04-30 14:46:03.236261 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277588792707438
2023-04-30 14:46:03.468280 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277577473685787
2023-04-30 14:46:03.818019 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277548810949775
2023-04-30 14:46:04.164807 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277520609798956
2023-04-30 14:46:04.938268 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277500588388951
2023-04-30 14:46:05.190166 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277492677368574
2023-04-30 14:46:05.381009 CEST: Got context for toot None
2023-04-30 14:46:05.569261 CEST: Got context for toot None
2023-04-30 14:46:05.806285 CEST: Got context for toot None
2023-04-30 14:46:06.071147 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277427017479396
2023-04-30 14:46:06.385175 CEST: Got context for toot https://hachyderm.io/@molly0xfff/110277406212701717
2023-04-30 14:46:06.618355 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277403042140890
2023-04-30 14:46:07.087143 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277372536710781
2023-04-30 14:46:07.280647 CEST: Got context for toot https://infosec.exchange/@letsencrypt/110277330853487925
2023-04-30 14:46:07.551330 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277313794402700
2023-04-30 14:46:07.858825 CEST: Got context for toot None
2023-04-30 14:46:08.042705 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277288237647630
2023-04-30 14:46:08.291210 CEST: Got context for toot None
2023-04-30 14:46:08.576282 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277236386461189
2023-04-30 14:46:08.844138 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277233622740975
2023-04-30 14:46:09.101976 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277212021469321
2023-04-30 14:46:09.344972 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277208013230715
2023-04-30 14:46:09.511098 CEST: Got context for toot None
2023-04-30 14:46:09.852875 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277162146720685
2023-04-30 14:46:10.146409 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110277127631853800
2023-04-30 14:46:10.738453 CEST: Got context for toot https://me.dm/@medium/110277098102140256
2023-04-30 14:46:10.996705 CEST: Got context for toot https://miau.le-chat-a-velo.at/@gudroot/110277091978958597
2023-04-30 14:46:11.296933 CEST: Got context for toot https://me.dm/@medium/110277082026859388
2023-04-30 14:46:11.575920 CEST: Got context for toot https://mstdn.social/@feditips/110277066748436943
2023-04-30 14:46:11.783407 CEST: Got context for toot https://die-partei.social/@rockpapershotgun/110277053835706776
2023-04-30 14:46:11.937552 CEST: Got context for toot https://die-partei.social/@rockpapershotgun/110277053818751147
2023-04-30 14:46:12.103205 CEST: Got context for toot https://social.anoxinon.de/@gnulinux/110277041942574433
2023-04-30 14:46:12.525619 CEST: Got context for toot None
2023-04-30 14:46:12.690062 CEST: Got context for toot https://social.anoxinon.de/@gnulinux/110276920047209560
2023-04-30 14:46:13.498565 CEST: Got context for toot None
2023-04-30 14:46:13.719726 CEST: Got context for toot https://mastodon.social/@TheMetalDog/110276879612552316
2023-04-30 14:46:13.872208 CEST: Got context for toot https://social.anoxinon.de/@gnulinux/110276857198094551
2023-04-30 14:46:14.092142 CEST: Got context for toot https://fnordon.de/@dentaku/110276849255710407
2023-04-30 14:46:14.363364 CEST: Got context for toot None
2023-04-30 14:46:14.586919 CEST: Got context for toot https://mastodon.social/@effinbirds/110276829769490527
2023-04-30 14:46:14.746832 CEST: Got context for toot https://social.anoxinon.de/@gnulinux/110276821774749914
2023-04-30 14:46:14.925921 CEST: Got context for toot None
2023-04-30 14:46:15.106759 CEST: Got context for toot https://mstdn.social/@anne_reko/110276664129404024
2023-04-30 14:46:16.098857 CEST: Got context for toot None
2023-04-30 14:46:16.329386 CEST: Got context for toot https://wien.rocks/@b2c/110276249144949514
2023-04-30 14:46:16.463010 CEST: Error getting context for toot https://wien.rocks/@b2c/110276227552133452. Status code: 404
2023-04-30 14:46:16.743699 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110276077745346285
2023-04-30 14:46:16.860116 CEST: Got context for toot https://aut.social/@bernhard/110276052889522079
2023-04-30 14:46:17.104108 CEST: Got context for toot None
2023-04-30 14:46:17.314641 CEST: Got context for toot https://aut.social/@bernhard/110275933579020836
2023-04-30 14:46:17.427206 CEST: Got context for toot https://aut.social/@bernhard/110275736908276618
2023-04-30 14:46:17.669279 CEST: Got context for toot None
2023-04-30 14:46:17.927980 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110275628684933945
2023-04-30 14:46:18.158319 CEST: Got context for toot None
2023-04-30 14:46:18.357435 CEST: Got context for toot https://mastodon.social/@Tzwehn/110275511558546966
2023-04-30 14:46:18.494321 CEST: Got context for toot https://social.anoxinon.de/@gnulinux/110275480880310117
2023-04-30 14:46:18.750618 CEST: Got context for toot https://mastodon.social/@Gargron/110275477450180746
2023-04-30 14:46:18.973046 CEST: Got context for toot https://aut.social/@bernhard/110275469960035857
2023-04-30 14:46:19.642861 CEST: Got context for toot https://social.tchncs.de/@kuketzblog/110275395111987768
2023-04-30 14:46:19.778521 CEST: Got context for toot https://aut.social/@bernhard/110275259603357479
2023-04-30 14:46:19.992562 CEST: Got context for toot None
2023-04-30 14:46:20.171217 CEST: Got context for toot https://social.tchncs.de/@random_musings/110275116769177577
2023-04-30 14:46:20.334593 CEST: Got context for toot https://social.tchncs.de/@random_musings/110274990756972594
2023-04-30 14:46:21.169074 CEST: Discovered redirect for URL https://social.kernel.org/objects/243003ef-27ba-437f-ac03-817ce5ce5d44
2023-04-30 14:46:21.948131 CEST: Got context for toot None
2023-04-30 14:46:22.730388 CEST: Got context for toot None
2023-04-30 14:46:24.509577 CEST: Got context for toot None
2023-04-30 14:46:24.731111 CEST: Got context for toot https://mastodon.social/@effinbirds/110273526704764993
2023-04-30 14:46:25.778606 CEST: Got context for toot https://mastodon.social/@Gargron/110273171231251728
2023-04-30 14:46:26.233568 CEST: Got context for toot None
2023-04-30 14:46:26.570518 CEST: Got context for toot https://mstdn.social/@feditips/110272968407733255
2023-04-30 14:46:26.977867 CEST: Got context for toot https://vis.social/@kristinHenry/110272751456172309
2023-04-30 14:46:27.175762 CEST: Got context for toot None
2023-04-30 14:46:27.376648 CEST: Got context for toot None
2023-04-30 14:46:29.218148 CEST: Got context for toot None
2023-04-30 14:46:29.913603 CEST: Got context for toot https://mastodon.social/@Gargron/110272552093771675
2023-04-30 14:46:30.211411 CEST: Got context for toot https://mastodon.social/@effinbirds/110272437511297642
2023-04-30 14:46:31.960662 CEST: Got context for toot None
2023-04-30 14:46:32.410376 CEST: Got context for toot https://hachyderm.io/@molly0xfff/110272369668582032
2023-04-30 14:46:32.608969 CEST: Got context for toot None
2023-04-30 14:46:32.941548 CEST: Got context for toot https://ublog.tech/@IPngNetworks/110272337565726554
2023-04-30 14:46:33.115736 CEST: Got context for toot https://social.tchncs.de/@random_musings/110272324702447476
2023-04-30 14:46:33.307300 CEST: Got context for toot https://troet.cafe/@MatsurikaGaming/110272237499466919
2023-04-30 14:46:33.575575 CEST: Got context for toot https://digitalcourage.social/@digitalcourage/110272104795912732
2023-04-30 14:46:33.944883 CEST: Got context for toot https://ublog.tech/@IPngNetworks/110272087920764263
2023-04-30 14:46:34.234323 CEST: Got context for toot https://ublog.tech/@IPngNetworks/110272080576874786
2023-04-30 14:46:34.819889 CEST: Got context for toot None
2023-04-30 14:46:34.983597 CEST: Got context for toot https://die-partei.social/@rockpapershotgun/110271922383169617
2023-04-30 14:46:35.201372 CEST: Got context for toot https://fosstodon.org/@kernellogger/110271840371490826
2023-04-30 14:46:35.504862 CEST: Got context for toot None
2023-04-30 14:46:35.663660 CEST: Got context for toot https://die-partei.social/@rockpapershotgun/110271568500694100
2023-04-30 14:46:35.820605 CEST: Got context for toot https://die-partei.social/@rockpapershotgun/110271568474404934
2023-04-30 14:46:35.990844 CEST: Got context for toot https://chaos.social/@epicenter_works/110271503091349499
2023-04-30 14:46:36.225003 CEST: Got context for toot None
2023-04-30 14:46:36.827751 CEST: Got context for toot None
2023-04-30 14:46:37.160753 CEST: Got context for toot None
2023-04-30 14:46:37.710992 CEST: Got context for toot None
2023-04-30 14:46:38.168658 CEST: Got context for toot None
2023-04-30 14:46:39.177043 CEST: Got context for toot None
2023-04-30 14:46:39.370396 CEST: Got context for toot https://mastodon.social/@effinbirds/110271167468759563
2023-04-30 14:46:39.567885 CEST: Got context for toot https://infosec.exchange/@letsencrypt/110270999391462646
2023-04-30 14:46:40.125687 CEST: Got context for toot None
2023-04-30 14:46:40.344928 CEST: Got context for toot https://wien.rocks/users/JohannesWidi/statuses/110270944343541422/activity
2023-04-30 14:46:40.502230 CEST: Got context for toot None
2023-04-30 14:46:40.658200 CEST: Got context for toot https://die-partei.social/@rockpapershotgun/110270605071395699
2023-04-30 14:46:40.838678 CEST: Got context for toot None
2023-04-30 14:46:41.138410 CEST: Got context for toot https://ublog.tech/@IPngNetworks/110270337707336834
2023-04-30 14:46:41.425272 CEST: Got context for toot https://cloud-native.social/@saiyam/110270279065933045
2023-04-30 14:46:41.590241 CEST: Got context for toot https://social.anoxinon.de/@gnulinux/110270219670504945
2023-04-30 14:46:41.828350 CEST: Got context for toot None
2023-04-30 14:46:42.131893 CEST: Got context for toot None
2023-04-30 14:46:43.182835 CEST: Got context for toot https://mastodon.sdf.org/@stokesauce/110269800784497124
2023-04-30 14:46:43.516417 CEST: Got context for toot None
2023-04-30 14:46:43.779105 CEST: Got context for toot https://fosstodon.org/@PCzanik/110269557855094446
2023-04-30 14:46:43.932177 CEST: Got context for toot https://chaos.social/@epicenter_works/110269527900074364
2023-04-30 14:46:44.363302 CEST: Got context for toot https://toot.community/@chewyadupp/110269515436485879
2023-04-30 14:46:44.512277 CEST: Got context for toot https://social.anoxinon.de/@gnulinux/110269488322074211
2023-04-30 14:46:44.690105 CEST: Got context for toot None
2023-04-30 14:46:45.371004 CEST: Got context for toot https://hachyderm.io/@nova/110269367617217766
2023-04-30 14:46:45.566677 CEST: Got context for toot https://mastodon.social/@Gargron/110269333177557613
2023-04-30 14:46:46.183055 CEST: Got context for toot https://hachyderm.io/@nova/110269313981320765
2023-04-30 14:46:46.689686 CEST: Got context for toot https://hachyderm.io/@nova/110269297502294936
2023-04-30 14:46:47.175635 CEST: Got context for toot https://hachyderm.io/@nova/110269282105849043
2023-04-30 14:46:47.513118 CEST: Got context for toot https://inkdrop.space/@erosdiscordia/110269280229568362
2023-04-30 14:46:47.824437 CEST: Got context for toot https://inkdrop.space/@erosdiscordia/110269243245040071
2023-04-30 14:46:48.378198 CEST: Got context for toot https://hachyderm.io/@nova/110269220095556570
2023-04-30 14:46:48.606689 CEST: Got context for toot https://hachyderm.io/@molly0xfff/110268968386952160
2023-04-30 14:46:48.786237 CEST: Got context for toot https://fosstodon.org/@kernellogger/110268967819554020
2023-04-30 14:46:49.318070 CEST: Got context for toot https://hachyderm.io/@nova/110268918980340570
2023-04-30 14:46:50.440705 CEST: Got context for toot https://hachyderm.io/@nova/110268918029141405
2023-04-30 14:46:51.465957 CEST: Got context for toot https://aus.social/@dgar/110268863255638200
2023-04-30 14:46:52.182279 CEST: Got context for toot None
2023-04-30 14:46:52.763132 CEST: Discovered redirect for URL https://mu.zaitcev.nu/objects/88c7f0cf-8490-42f6-98cb-357ccaf3cb99
2023-04-30 14:46:53.189954 CEST: Got context for toot None
2023-04-30 14:46:53.402683 CEST: Got context for toot https://mastodon.xyz/@xkcd/110268722552200407
2023-04-30 14:46:53.693705 CEST: Got context for toot None
2023-04-30 14:46:54.041336 CEST: Got context for toot None
2023-04-30 14:46:54.634407 CEST: Got context for toot None
2023-04-30 14:46:55.115542 CEST: Got context for toot https://mstdn.social/@feditips/110268251644500447
2023-04-30 14:46:55.447154 CEST: Got context for toot https://hachyderm.io/@molly0xfff/110268095363254922
2023-04-30 14:46:55.841017 CEST: Got context for toot https://hachyderm.io/@molly0xfff/110267962281429565
2023-04-30 14:46:56.283984 CEST: Got context for toot https://hachyderm.io/@molly0xfff/110267960470755209
2023-04-30 14:46:57.152408 CEST: Got context for toot https://hachyderm.io/@molly0xfff/110267958305946394
2023-04-30 14:46:57.755944 CEST: Got context for toot https://hachyderm.io/@molly0xfff/110267954441141833
2023-04-30 14:46:57.974467 CEST: Got context for toot https://mastodon.social/@effinbirds/110267864444585741
2023-04-30 14:46:59.122910 CEST: Got context for toot None
2023-04-30 14:47:00.339611 CEST: Got context for toot None
2023-04-30 14:47:00.751785 CEST: Got context for toot https://vis.social/@kristinHenry/110267385626309088
2023-04-30 14:47:01.039472 CEST: Got context for toot None
2023-04-30 14:47:01.256044 CEST: Got context for toot None
2023-04-30 14:47:02.127871 CEST: Got context for toot None
2023-04-30 14:47:03.023798 CEST: Got context for toot None
2023-04-30 14:47:03.237688 CEST: Got context for toot None
2023-04-30 14:47:03.237963 CEST: Error parsing toot URL https://anonsys.net/display/bf69967c-6664-495d-6e3a-a16077737418
2023-04-30 14:47:03.464355 CEST: Got context for toot None
2023-04-30 14:47:03.759425 CEST: Got context for toot None
2023-04-30 14:47:04.571270 CEST: Got context for toot None
2023-04-30 14:47:04.768953 CEST: Got context for toot None
2023-04-30 14:47:04.769156 CEST: Found 1859 known context toots
2023-04-30 14:47:05.253623 CEST: Added context url https://hachyderm.io/@stonebear/110269174273720816
2023-04-30 14:47:06.171568 CEST: Added context url https://mas.to/@franktaber/110268962862261293
2023-04-30 14:47:06.565568 CEST: Added context url https://mastodon.social/@pyperkub/110269038468994433
2023-04-30 14:47:09.080065 CEST: Added context url https://social.lol/@phils/110269234773434347
2023-04-30 14:47:09.548012 CEST: Added context url https://mastodon.art/@uddelhexe_/110269033565678512
2023-04-30 14:47:10.527234 CEST: Added context url https://hachyderm.io/@draNgNon/110269301944296433
2023-04-30 14:47:11.499143 CEST: Added context url https://infosec.exchange/@pauliehedron/110269181824790212
2023-04-30 14:47:11.911545 CEST: Added context url https://hachyderm.io/@nova/110269220095556570
2023-04-30 14:47:12.354845 CEST: Added context url https://hachyderm.io/@NireBryce/110269005285559581
2023-04-30 14:47:12.714733 CEST: Added context url https://chaos.social/@D_70WN/110269184839438600
2023-04-30 14:47:13.587585 CEST: Added context url https://social.anoxinon.de/@hias1234/110269099149667792
2023-04-30 14:47:14.650278 CEST: Added context url https://hachyderm.io/@pierrenick/110269269275955676
2023-04-30 14:47:15.024992 CEST: Added context url https://hachyderm.io/@nova/110269282105849043
2023-04-30 14:47:15.421080 CEST: Added context url https://hachyderm.io/@nova/110269297502294936
2023-04-30 14:47:15.957525 CEST: Added context url https://layer8.space/@tunda/110287819018434926
2023-04-30 14:47:17.046601 CEST: Added context url https://scicomm.xyz/@unchartedworlds/110269264471517167
2023-04-30 14:47:17.378024 CEST: Added context url https://chaos.social/@uschebit/110287732721818262
2023-04-30 14:47:17.934715 CEST: Added context url https://hachyderm.io/@thisismissem/110268958766590663
2023-04-30 14:47:18.890912 CEST: Added context url https://hachyderm.io/@log1kal/110269080698986186
2023-04-30 14:47:18.891350 CEST: Added 19 new context toots (with 0 failures)
2023-04-30 14:47:19.141591 CEST: Error getting user ID for user<EMAIL_ADDRESS>User bba was not found on server digitalcourage.video/video-channels.
2023-04-30 14:47:19.301204 CEST: Error getting user ID for user<EMAIL_ADDRESS>User digitalcourage.de was not found on server digitalcourage.video/accounts.
2023-04-30 14:47:19.436111 CEST: Error getting user ID for user<EMAIL_ADDRESS>User digitalcourage.de was not found on server digitalcourage.video/accounts.
2023-04-30 14:47:19.989980 CEST: Error getting user ID for user<EMAIL_ADDRESS>Error getting URL https://types.pl/api/v1/accounts/lookup?acct=amy. Status code: 401
2023-04-30 14:47:20.512800 CEST: Error getting user ID for user<EMAIL_ADDRESS>Expecting value: line 1 column 1 (char 0)
2023-04-30 14:47:20.864293 CEST: Error getting user ID for user<EMAIL_ADDRESS>Expecting value: line 1 column 1 (char 0)
2023-04-30 14:47:21.850797 CEST: Error getting user ID for user<EMAIL_ADDRESS>User smj was not found on server toobnix.org/accounts.
2023-04-30 14:47:22.451513 CEST: Job failed after 0:02:12.227224.
Traceback (most recent call last):
  File "/app/find_posts.py", line 878, in <module>
    add_user_posts(arguments.server, token, filter_known_users(mentioned_users, all_known_users), recently_checked_users, all_known_users, seen_urls)
  File "/app/find_posts.py", line 75, in add_user_posts
    if post['reblog'] == None and post['url'] != None and post['url'] not in seen_urls:
                                  ~~~~^^^^^^^
KeyError: 'url'

Thanks @b2cc
Can I ask what software you are running on your server? Is yours a Mastodon server, or another Fediverse software?

@nanos : That was on  Mastodon 4.1.2

Thanks @b2cc
Can you check out the logging branch please, and re-run this. Then please provide another log, so I can check it out.

@b2cc Have you had any luck?

I'm having the same issue. I don't know much python. Is it possible to put that post['url'] line in a try/except so that the script can continue on error?
...
2023-06-01 12:14:08.208949 UTC: Added 5 new context toots (with 0 failures)
2023-06-01 12:14:08.716490 UTC: Added context url https://mastodon.ie/@oisin/110435054654347819
2023-06-01 12:14:09.328837 UTC: Got context for toot https://mastodon.ie/@oisin/110435054654347819
2023-06-01 12:14:09.328906 UTC: Found 1 known context toots
2023-06-01 12:14:09.838129 UTC: Added context url https://mastodon.ie/@davey_cakes/110434478837185550
2023-06-01 12:14:09.838434 UTC: Added 1 new context toots (with 0 failures)
2023-06-01 12:14:10.348901 UTC: Added context url https://mastodon.ie/@oisin/110434164792279434
2023-06-01 12:14:10.787037 UTC: Got context for toot https://mastodon.ie/@oisin/110434164792279434
2023-06-01 12:14:10.787106 UTC: Found 1 known context toots
2023-06-01 12:14:11.251085 UTC: Added context url https://wandering.shop/@cstross/110430471006309334
Traceback (most recent call last):
2023-06-01 12:14:11.251149 UTC: Added 1 new context toots (with 0 failures)
  File "/home/runner/work/mastodon_get_replies/mastodon_get_replies/find_posts.py", line 878, in <module>
2023-06-01 12:14:11.762091 UTC: Added context url https://mastodon.ie/@oisin/110434135460840287
    add_user_posts(arguments.server, token, filter_known_users(mentioned_users, all_known_users), recently_checked_users, all_known_users, seen_urls)
2023-06-01 12:14:12.309015 UTC: Got context for toot https://mastodon.ie/@oisin/110434135460840287
2023-06-01 12:14:12.309086 UTC: Found 2 known context toots
  File "/home/runner/work/mastodon_get_replies/mastodon_get_replies/find_posts.py", line 75, in add_user_posts
2023-06-01 12:14:12.603916 UTC: Added context url https://mastodon.social/@macpsych/110434505925631705
    if post['reblog'] == None and post['url'] != None and post['url'] not in seen_urls:
KeyError: 'url'
2023-06-01 12:14:12.964891 UTC: Added context url https://mastodon.social/@macpsych/110430378845[538](https://github.com/mattlehrer/mastodon_get_replies/actions/runs/5144126856/jobs/9260021931#step:8:539)628
2023-06-01 12:14:12.964957 UTC: Added 2 new context toots (with 0 failures)
2023-06-01 12:14:12.964972 UTC: Added 21 posts for user<EMAIL_ADDRESS>with 0 errors
2023-06-01 12:14:17.831918 UTC: Job failed after 0:04:30.976265.
Error: Process completed with exit code 1.

I'm kinda glad you have been able to reproduce this.
I'd be grateful if you could send in the log from the logging branch. Hopefully that'll tell me more.

Well, I don't have the best news, in some ways. I upgraded to the latest Hometown version right before this started failing, so there's probably some change from 4.0.2 to 4.0.4 that causes this. Every run on GitHub Actions failed after that.
I cloned the repo to my server and ran the script there. Unfortunately, it worked perfectly while I had the output going to stdout. It had a lot to catch up on and ran for a long time (the GH actions jobs were all failing around 9 - 11 minutes, the script ran for probably 35 minutes before I killed it thinking I should be saving the logs).
I then ran it again with the output piped to a file. The line Error adding post does not appear in those logs. So I guess I missed that exception. And now the GH Actions runs are working again. So it must have been a rare toot circumstance that caused it.
I do think the try/except block is more likely the thing that fixed the problem vs the problem toot being far enough back in the timeline that it didn't get the FediFetcher treatment. If the GH Actions runs start failing again, I will make sure to catch the logs.

Hm. Very strange. It does appear to only happen in a very rare edge case, based on the fact that there have only been very few reports of this so far.
I'd love to track this down!

    if post['reblog'] == None and post['url'] != None and post['url'] not in seen_urls:
KeyError: 'url'

This particular exception will be solved by e290f2c (#56) by replacing post['url'] with post.get('url') which will return None if the property does not exist in the dictionary, instead of producing a KeyError.

Thanks so much @Teqed! I'm closing this as fixed with the release of v6.0.0


Fixed t2ramsey_tutorial following recent changes

Summary
Fixed tutorial following changes from PR #115 .
Details and comments

Ready for review.


Option to lock sizes within a group

Currently, when a group of items is scaled, all items inside the group are scaled proportionally. There is no feature to lock the dimensions of specific items within the group.
Feature Request:
Add an option to lock the dimensions of individual items in a group so they remain unchanged during group scaling. This would provide more flexibility when working with grouped elements, especially when certain items need to maintain their original size.

Isn't ungrouping, scaling just the rectangle, and grouping again essentially what you want?

In the GIF, I meant that if you scale a group of items, everything inside the group scales together. There's no feature to "lock" an item's size, so even if you want one item to stay the same, it will still scale when the group does.

Should I delete this issue and recreate one? Seems kinda confusing I guess

My issue was very confusuing so I updated it. I hope it is much understandable now


[Microsoft.App] targetLabel and Labels revision mode

ARM (Control Plane) API Specification Update Pull Request

[!TIP]
Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Purpose of this PR
add new property targetLabel and also new activeRevisionsMode labels
original PR here, but closed due to merge issues https://github.com/Azure/azure-rest-api-specs/pull/30509
What's the purpose of this PR? Check the specific option that applies. This is mandatory!

[ ] New resource provider.
[x] New API version for an existing resource provider. (If API spec is not defined in TypeSpec, the PR should have been created in adherence to OpenAPI specs PR creation guidance).
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix OpenAPI spec quality issues in S360.
[ ] Convert existing OpenAPI spec to TypeSpec spec (do not combine this with implementing changes for a new API version).
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[ ] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
[ ] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.

Additional information

 Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
suppressions guide to get approval.

Getting help

First, please carefully read through this PR description, from top to bottom. Please fill out the Purpose of this PR and Due diligence checklist.
If you don't have permissions to remove or add labels to the PR, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories
To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
For help with ARM review (PR workflow diagram Step 2), see https://aka.ms/azsdk/pr-arm-review.
If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run.
This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

Pl fix the errors here - https://github.com/Azure/azure-rest-api-specs/pull/30802/checks?check_run_id=30881064450

/azp run

@rkmanda all the issues have been addressed this is ready for review again

/pr RequestReview


fix: batcher queue ord

[!IMPORTANT]
This PR is a rebase from #1637

Fix batcher queue ord
Description
There was a bug in the batcher queue ordering of elements, which led to a wrong placement of proofs when a same sender sent proofs with same max_fee.
The consecuence of this bug was seen when the batcher queue is filled, the proofs sent to chain will be not from lowest to highest nonce, but the other way around.
To Test
You can view the unit tests.
Also you can add the following print statements (and can do before this PR so you can verify the bug indeed existed).
in batcher/aligned-batcher/src/lib.rs, line 1175:
        info!("resulting:");
        for (entry, _priority) in resulting_batch_queue.iter() {
            info!(
                "nonce: {:?}, max fee: {:?}",
                entry.nonced_verification_data.nonce, entry.nonced_verification_data.max_fee
            );
        }

        info!("finalized:");
        for entry in finalized_batch.iter() {
            info!(
                "nonce: {:?}, max fee: {:?}",
                entry.nonced_verification_data.nonce, entry.nonced_verification_data.max_fee
            );
        }

in messaging.rs, line 161:
        info!("Last proof nonce: {:?}", last_proof_nonce);
        info!("Current proof nonce: {:?}", batch_inclusion_data_message.user_nonce);

This will help to view the resulting state of the batcher queue.
To execute the bug you should send a burst bigger than the batch_qty limit. For this it is recommended to lower this value, config-batcher.yaml:
  max_batch_proof_qty: 5 # 5 proofs in a batch, for testing

Then send a burst of size 8, so that the first batch is of size 5 and the second of size 3. (this ensures you don't get the batch already submitted contract revert).
For this you can set BURST_SIZE ?= 8 in the Makefile.
Type of change

[ ] New feature
[x] Bug fix
[ ] Optimization
[ ] Refactor

Checklist

[x] “Hotfix” to testnet, everything else to staging
[ ] Linked to Github Issue
[ ] This change depends on code or research by an external entity

[ ] Acknowledgements were updated to give credit

[x] Unit tests added
[ ] This change requires new documentation.

[ ] Documentation has been added/updated.

[ ] This change is an Optimization

[ ] Benchmarks added/run

[ ] Has a known issue

Link to the open issue addressing it

[ ] If your PR changes the Operator compatibility (Ex: Upgrade prover versions)

[ ] This PR adds compatibility for operator for both versions and do not change batcher/docs/examples
[ ] This PR updates batcher and docs/examples to the newer version. This requires the operator are already updated to be compatible

make test doesn't seem to run the batcher's tests. We might want to change that later.


Diagnostics keeps showing even if I delete the error line.

Thanks for your great work !
I use bingo in vim with LanguageClient-Neovim. And after I typed something wrong in a new line, the diagnostics shows in the gutter. But diagnotics keeps showing even if I fixed it or just delete the error line.

Show variable as not used, but this compiles with go build.

@imjustfly @anjmao
I have fixed this first bug.

@anjmao
How to reproduce the second question?

@saibing It works. Thanks!

@saibing

Create

package main

import "fmt"

func main() {
	fmt.Println("hello")
}

Now make invalid syntax, remove Println ending bracket

package main

import "fmt"

func main() {
	fmt.Println("hello"
}

Now save the code

result
package main

import "fmt"

func main() {
	fmt.Println("hello",
		BadExpr,
	)
}

@anjmao
Thank you very much.
I have fixed the bug, please update to the latest version


Positional tracking not working in 6DOF using the latest SDK

I've tested the provided demo, and Firefox Reality, with the latest SDKs and the position received for the head (either by using xrLocateSpace or xrLocateViews) doesn't get correct values for HMD head position.
Positional tracking works in the system app launcher, but not in OpenXR (based on testing the demo and FxR). Do you have the same problem? Is there any service I need to update?

It is a bug,  which is already in the settlement plan.

I guess your application did not add 6DOF label.  To get hemet position, it must be a 6DOF app. You can make your application recognized as a 6dofapp by SDK through the following operations.
In AndroidManifest.xml, add:

More details can be referred at the following website.
[https://developer.huawei.com/consumer/cn/doc/development/graphics-Guides/configuration-manifest-0000001205526407]

Thanks, we didn't have that label in the manifest, I created a new demo with 6DOF fixed (https://github.com/hms-ecosystem/OpenXR-SDK/tree/main/demos/demo_november9)
Now I can also get both the head & controllers on the same reference space, so I based everything on the floor transform to provide correct user height and controller heights


Switch to MIT license

I noticed this package uses the GPL-3 license. Is there any particular reason for this? Using GPL-3 may limit this package's adoption. Would you be opposed to switching the package to the MIT license?

I'm not necessarily opposed. Who do you think would not use it under GPL-3 but would use it under MIT?

@omus commented on Jun 3, 2020, 9:38 PM GMT+4:30:

I noticed this package uses the GPL-3 license. Is there any particular reason for this? Using GPL-3 may limit this package's adoption. Would you be opposed to switching the package to the MIT license?

Freedom doesn't come for free. GPL gives free software developers a competitive edge.

There's a good Discourse post on mixing MIT and GPL packages: https://discourse.julialang.org/t/gpl-and-virality/7715. In my use case GPL isn't an issue I just wanted to ensure the choice of the GPL license was intentional.

Thanks, that's a good article. Indeed the choice was intentional.

https://github.com/invenia/LibPQ.jl/issues/209

@omus I don't use this package much any more, would you be interested in maintaining it? I'd be happy to re-licence it as MIT.

He's away on leave for a while but I can commit on behalf of Invenia, which includes @omus and @fchorney.

I detect a communication gap and shall insert myself to generate alert e-mails.
@cjdoris are you amenable to the proposal?

I detect a communication gap and shall insert myself to generate alert e-mails.
@cjdoris are you amenable to the proposal?

I'm happy to relicense this as MIT and add @omus and @fchorney as collaborators.

I'm happy to relicense this as MIT and add @omus and @fchorney as collaborators.

How can we make this happen? It's a bit of a problem in the Julia ecosystem (via libPQ and Intervals)
In https://github.com/cjdoris/Infinity.jl/graphs/contributors I see that all contributors are in the discussion above, so presumably there are not other contributors to agree to the license change. Do any of the original contributors to this discussion make the change? If you need help with anything then the RelationalAI team can help too.

I have merged the PR to relicense this as MIT, thanks.
Note (see #25) that there is a new package Infinities.jl which combines ideas from this package and some other places. The intention is that everything is this package ends up there and we deprecate this one. It has types to represent unsigned/signed/complex infinity. The main thing from this package not there is InfExtendedReal etc.


[Help] Does copyparty support suburls?

I want to use copyparty as a simple file sharing service on my own server. And because I don't use domains (using NoIP currently :P) I wanted to ask if copyparty supports suburls? I've implemented a Apache² reverse proxy setup and it does not work correctly (as seen in the screenshot below). Can I somehow fix it (by implementing it manually or changing something in the args/config)?
A screenshot displaying a broken copyparty installation with DevTools network monitoring enabled:

Hey! and thanks for giving copyparty a go :+1:
You guessed it, that wasn't supported yet -- but it's time to fix that. Next version will have a new argument --webroot where you can provide the suburl you've placed copyparty at.
Please grab the beta if you'd like, and let me know if it explodes :>

Thank you for the fast response :)
I'll try the beta and respond if it works or exploded.

Thank you! It worked first try.
But, copyparty seems to ignore the --webroot argument sometimes and the console throws this error every time I visit copyparty:
incorrect --webroot or webserver config; expected vpath starting with [share] but got []
Anyway, I can upload files now, so thank you anyway!

Nice! Glad to hear it mostly worked. But I'd like to figure out what's going on with the URL rewriting, especially if it turns out to be a bug on my end :>
copyparty will only print that message if it gets the x-forwarded-for header, which is added by apache on the way in, so I believe all the requests are coming through apache like they should. Did you perhaps do some URL rewriting in the apache config with mod_rewrite or similar? If yes, please try to disable those.
If that doesn't help, did you notice any pattern in which requests are being rejected? Maybe it'll become more obvious by enabling --ihead=* to see all incoming headers.

I don't actually have any rewring enabled for /share/ (where copyparty lives), only for old paths like /sync/ that redirect to /syncthing/ on my server, so that should not be a problem. I may try enabling --ihead=* later because I currently don't have time for that. Still thank you. If I have any more information regarding this, I'll update you here.

no worries! I'll try an apache setup too, only ever tested with nginx so far :+1:

okay, think I got it -- apache strips away the location from the request url, so you have to include it in the ProxyPass command, making it ProxyPass "/stuff" "http://<IP_ADDRESS>:3923/stuff" for example :>

Hello,
Did you merge the improvement?
Can't find webroot argument in docker run --rm -it copyparty/ac --help.
Thank you!


feat: Add pip-tools compiled lock file for reproducibility

This PR uses pip-tools to generate a hash level lock file of the analysis environment using pip-compile to ensure reproducibility of results. The motivation for this is to avoid API drift/breakage and to avoid subtle result differences that can arise from low level changes between minor and patch releases of libraries. The analysis is like an application, and so defining an explicit environment in which the analysis was performed in allows for greater ease of reproduction and reuse.
The PR does this by doing 1 things:

Pinning the library high level requirements defined in requirements.txt to specific versions.

This is done to give pip-compile a unchanging high level requirements to compile the full dependency list against.

Use pip-tools's pip-compile command to generate a lock file from the high level requirements.txt that defines the analysis environment down to the hash level. This is done with the command

pip-compile --generate-hashes --output-file requirements.lock requirements.txt

Notes on use
Updating the environment lock file
The lock file is kept under version control but should never be manually updated. To update the environment the maintainer (@lukasheinrich) would:
0. Ensure pip-tools is installed:
python -m pip install --upgrade pip setuptools wheel && python -m pip install --upgrade pip-tools

Update the version of the pinned requirements to be updated in requirements.txt.
Regenerate the lock file with

pip-compile --generate-hashes --output-file requirements.lock requirements.txt

Commit both the updated requirements.txt and requirements.lock to version control.

Installing the environment
To ensure that the lock file is fully descriptive of the environment and to leverage the hash level information in it, the environment should optimally be installed using pip with the options that are described by Brett Cannon to be "secure-install":
python -m pip install --no-deps --require-hashes --only-binary :all: --requirement requirements.lock

The options used to follow pip-secure-install recommendations are:

A requirements file must be specified to make sure all dependencies are known statically for auditing purposes (--requirement).
No dependency resolution is done to make sure the requirements file is complete (--no-deps).
All requirements must have a hash provided to make sure the files have not been tampered with (--require-hashes).
Only wheels are allowed to have reproducible installs (--only-binary :all:).

This ensures that the installed environment is exactly the one described in the lock file, and not an environment that is the lock file plus additional mutations. For more on secure-install c.f.:

https://www.python.org/dev/peps/pep-0665/#secure-by-design
https://github.com/brettcannon/pip-secure-install
https://twitter.com/brettsky/status/1486137764315688961

Further considerations
It might be worth communicating in some way that while the requirements.txt offers a high level view of the requirements, it is pinned for the benefit of lock file generation and not because the analysis code will break without these particular versions.

@lukasheinrich This is ready for review. I'm more than happy to answer any questions, make any changes, and discuss any points you might have. :+1:

Thanks @matthewfeickert as always!


Distribute and publish package to Bintray

It would be great to publish java-libbitcoinconsensus to Bintray, so that it can easily be added to other projects.

I created https://bintray.com/dexx7/maven/java-libbitcoinconsensus/.
Ideally the process would be automated, and with each release (on GitHub), a new version is published.
Is there a good way to handle snapshots?

Travis might be used to automate it:
http://docs.travis-ci.com/user/deployment/bintray/
http://docs.travis-ci.com/user/deployment/#Conditional-Releases-with-on%3A


[IR] Create a utility for merging models

This is useful for merging separately exported models like whisper. The main thing to handle is name collision. We may need to improve the name_authority to make this eaiser.
Ref: Spox's api for merging models.

"May I work on this issue?"


🎨 [Design] : Admin campaign publishing workflow

@mike-mcnulty I did a minimal implementation of a Campaign Management Modal - Accessed through the top navigation. Top navigation also shows Draft / Published chip.
See Figma
Summary
Schedule and publish campaign
Description
As an admin user, I need to be able to publish campaigns, so that my community can participate in them. I want to be able to schedule them, so that I can set and forget campaigns once they are finalized.
AC

User can save a campaign as a draft viewable only by other brand admins
Users can configure / edit everything on draft campaigns
Users can only edit copy on specific fields on live campaigns
User can publish a finalized campaign for viewing by end users across spaces
User can schedule auto-publish at a specific datetime in the future

User can toggle between local timezone and UTC when scheduling campaign

Out of scope (post MVP)

Admin team consensus workflow before publishing

Open Questions:

Does anything with campaign definition need to be posted to chain (along with proposals, votes rollup)
Will admin API keys be signing anything? If so, should we introduce unlock password for admin role?
Does admin need ability to retract / reschedule a published campaign?
Discuss auto-create template for future use at point of publishing
do we need ability to retract / de-publish an active fund?
once in published state, which fields should be editable vs should be locked for editing?
each completed fund auto saved as a new event / category template?
metadata needed from admin view ie last updated, version history (auditing needs)?
confirm: only need to see current, upcoming, and draft events in main menu; all historical events saved on archive / detail page

@nielskijf @b-farrington anything outstanding here or design ticket can be closed?


[Question] Confusions about list

Confusion 1:
In help, it says
                        4 - Download from list
                            (optional: followed by path to list and optional tag)

But I failed to find a way to follow a "path to list":
Tried py -2 PixivUtil2.py -s 4 list2.txt, doesn't work. It still will only read hard-coded list.txt.
Confusion 2:
It seems that you have to enable "uselist" in Settings to enable any list-related functionality.
However, the description in help file:
uselist       ==> set to 'True' to parse list.txt.
                  This will update the DB content from the list.txt (member_id
                  and custom folder).

gives me the impression that even when it is False, you should still be able to manually download from list.txt using 4, just that it won't be added to database.

It should take the list as the argument. Please note that the list must be in the downloadListDirectory from config.ini

https://github.com/Nandaka/PixivUtil2/blob/master/PixivUtil2.py#L2248
https://github.com/Nandaka/PixivUtil2/blob/master/PixivUtil2.py#L1704

Yep, it just won't import the ids from the list to the db.

It should take the list as the argument. Please note that the list must be in the downloadListDirectory from config.ini

https://github.com/Nandaka/PixivUtil2/blob/master/PixivUtil2.py#L2248
https://github.com/Nandaka/PixivUtil2/blob/master/PixivUtil2.py#L1704

I tried it again, it will only parse the list file if uselist is set to False, and even then, it doesn't seem to work:
PixivDownloader2 version 20191105-beta2
https://github.com/Nandaka/PixivUtil2/releases
Donate at https://bit.ly/PixivUtilDonation
Reading g:\_temp\PixivUtil2\config.ini ...
done.
Using default DB Path: g:\_temp\PixivUtil2\db.sqlite
Creating database... done.
Using Username: fireattack
Trying to log in with saved cookie
Login successful.
My User Id: 222813.
Premium User: False.
Processing member id from .\list2.txt
Processing from database.
Found 0 items.
PixivDownloader2 version 20191105-beta2
https://github.com/Nandaka/PixivUtil2/releases
Donate at https://bit.ly/PixivUtilDonation

(My list2.txt file has a single ID of 14438469, but it doesn't parse it.)

DB update only parse from list.txt
https://github.com/Nandaka/PixivUtil2/blob/master/PixivUtil2.py#L2334

DB update only parse from list.txt
https://github.com/Nandaka/PixivUtil2/blob/master/PixivUtil2.py#L2334

I get that, the problem is if processFromDb is set to true and called, it won't parse the list you passed as an argument (because it is in else)

Understood that, but I'm just trying to download from a list file, not want to add members to the DB

will update to skip the list.txt import to db if it doesn't exits.


Python/add pyodide

Mostly copied from https://github.com/microsoft/typespec/pull/4784, thank you @YalinLi0312

No changes needing a change description found.

You can try these changes here

🛝 Playground
🌐 Website
📚 Next docs

Tested the following scenario:
With no Python env:

Install with no Python env, and compile with Python env:

Compile with Python env lower than 3.8:


PanelBuilder.withOverride does not append override

When setting the override config of the PanelBuilder classes using withOverride method, no overrides are actually appended. Looking at the compiled JS it seems to be a bug with either cog or how this method is setup:
    // Overrides are the options applied to specific fields overriding the defaults.
    withOverride(matcher, properties) {
        if (!this.internal.fieldConfig) {
            this.internal.fieldConfig = dashboard.defaultFieldConfigSource();
        }
        if (!this.internal.fieldConfig.overrides) {
            this.internal.fieldConfig.overrides = [];
        }
        this.internal.fieldConfig.overrides.push();
        return this;
    }

Hey!
Thanks for reporting this. You're correct, it's caused by a bug in cog. I started working on a fix there: https://github.com/grafana/cog/pull/203

happy new year and thanks for getting the fix out so quickly!


fix: disable namespace selection elements if a namespace is being dep…

…loyed
This PR...
Changes

Fixes

#1374

How to test it

Screenshots

Checklist

[X] tested locally
[ ] added new dependencies
[ ] updated the docs
[ ] added a test

Nice.
When choosing multiple components to deploy, a namespace included, it enables the selector.
I think for now this should work, just in case someone is trying to deploy multiple resources at the same time; but maybe in the future we could make it smarter by figuring out if the other resources make use of the same namespace being created.

thanks @aabedraba for testing - we could detect this scenario - i.e. if

the user is deploying multiple resources
the set of resources contains a Namespace resource
all other resources target that namespace
and in that scenario disable the namespace selector!?

How should we handle if the above is true except that not all resources target this namespace!? Perhaps an updated design of this interaction is needed - we could show a list of all resources with a selectable target namespace next to them - disabled for Namespace resources!? (this would be a separate issue)

we could show a list of all resources with a selectable target namespace next to them

I think this would be great, albeit only showing the list of resources without namespaces defined for them.

thanks @aabedraba - i've created https://github.com/kubeshop/monokle/issues/1376 for this - please add any more comments there!


ignite new PizzaApp broken from documentation

Hey there! Ignite seems to be having a problem, eh?
Welllllll, it just might be. First, search the issues to make sure it's not already
here, and if not head over to http://community.infinite.red to
get some help. If you've identified that it's really an Ignite issue, then:

Explain what's going on and preferably how to replicate the issue (bonus points for a repro app)
Run ignite doctor and paste the result below, including the lines with 3 backticks
Delete these instructions! We don't want to look at them. ;)

What's going on?
$ ignite new PizzaApp
/usr/local/lib/node_modules/ignite-cli/src/cli/check.js:2
const { nodeVersion, isNewEnough, hasAsyncAwait } = require('gluegun/sniff')
      ^

SyntaxError: Unexpected token {

Steps to reproduce
npm install -g ignite-cli
ignite new PizzaApp

ignite doctor results:
$ ignite doctor
/usr/local/lib/node_modules/ignite-cli/src/cli/check.js:2
const { nodeVersion, isNewEnough, hasAsyncAwait } = require('gluegun/sniff')
      ^

SyntaxError: Unexpected token {
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:387:25)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)
    at Object.<anonymous> (/usr/local/lib/node_modules/ignite-cli/bin/ignite:6:1)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)

I reckon you're running Node 4?  Type node -v.

I have the same issue. I am running node version 5.7.1

You'll need Node 7.6.  That's when they released the new await/async features.

yeah I have v5.10.1
upgrading now to see if this fixes it :)

You may need to npm i -g ignite-cli right after you install the new tools.


Refactoring constructor of parallel cubed sphere

WIP ... do not merge yet

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 0% with 178 lines in your changes missing coverage. Please review.

Project coverage is 0.00%. Comparing base (cf19338) to head (5125cfb).
Report is 17 commits behind head on master.

Files with missing lines
Patch %
Lines

src/ParseCubedSphereDiscreteModels.jl
0.00%
158 Missing :warning:

src/mpi/CubedSphereDistributedDiscreteModels.jl
0.00%
20 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master     #41    +/-   ##
=======================================
  Coverage    0.00%   0.00%
=======================================
  Files          18      19     +1
  Lines        1277    1592   +315
=======================================
- Misses       1277    1592   +315

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


test dataset use different scale mode from training dataset

In the train_gen.py file, the scale way of the dataset is shape_unit, but the test_gen.py used shape_bbox, why they are not the same?

The testing program renormalizes the point clouds despite the scale generated by the model.
We used shape_bbox in testing because previous work (ShapeGF) uses it.


pull request for e2e test at 01/08/2017 16:45:11

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[Feature] - db class memory improvements

The db class in the main is used for query and getAsClass both of these pull back all of the results from the db into memory before returning the value to the calling function. yield options could be used so that not all objects are loaded into memory at any given time reducing the memory overheads.
Within production systems I have been running jimi I have not come across this as an issue but could be a future improvement.

Adding such functionality that is currently not required even on very loaded systems would just result in massive amount of rework on the core and built plugins without any real gain.


Unlocking app on a "Twist". Bangle.js 2

I don't know whether it's an intended behavior, but when I twist (after lock), screen becomes unlocked, but not highlighted. So I can scroll and tap, but it's gray as far as I don't click the button.
It kinda makes sense, but looks as a bug at the same time, because there is no setting to change it, so I decided to report it, just in case.
Can record a video if needed.

Thanks - however you just need to update your Bangle's firmware: https://www.espruino.com/Bangle.js2#firmware-updates
This was fixed a few weeks back but the fix couldn't be done in JS - it had to be in the watch firmware itself.


add metapath info fill-in functionality

Tooltip text says:
The info for metapath was not pre-computed because it was below a threshold of importance. Click to compute it now.


DEVPROD-843 Add warnings section to distro settings

DEVPROD-843
Description
Adds a section to distro settings to allow inputting warnings
Screenshots

Testing
unit tests and manual testing
Evergreen PR
https://github.com/evergreen-ci/evergreen/pull/7756

Can you add a test to cypress/integration/distroSettings/general_section.ts? Where will the message be rendered?

Added a test! The message will be rendered as a yml validation warning.

@ablack12 I followed up with Brian and he mentioned that this feature would be most valuable as a validation step I am updating this pr so that the field will be hidden in the UI and can be reenabled by swapping a constant and reenabling the tests.


Fix empty docker namespace

Signed-off-by: Ivana Yovcheva<EMAIL_ADDRESS>This resolves #11
Description

Motivation and Context

[ ] I have raised an issue to propose this change (required)

How Has This Been Tested?

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I've read the CONTRIBUTION guide
[x] I have signed-off my commits with git commit -s
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Let's try it out.. 👍


Cannot create Kafka ACL CRD

I am unable to create a Kafka ACL CRD
Using helm and the configuration in the docs The ServiceUser is created but the ACL fails with the following error:
Events:
  Type     Reason                Age                   From                  Message
  ----     ------                ----                  ----                  -------
  Warning  UnableToAddFinalizer  18m (x12 over 19m)    kafka-acl-reconciler  kafkaacls.aiven.io "crab" is forbidden: User "system:serviceaccount:default:default" cannot update resource "kafkaacls" in API group "aiven.io" in the namespace "default"
  Normal   ReconcilationStarted  8m13s (x18 over 19m)  kafka-acl-reconciler  starting reconciliation

Using Kafka v2.8.1

The KafkaACL resource is missing the RBAC for updates; we need to add it and regenerate our deployments.

Looks like it's been covered by #172


✨ succinct documentation for resource groups

cc @Kakulukian @coyotte508 @Pierrci if I missed something or wrote anything wrong
Ping @Michellehbn for a native speaker review 🙏

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


mockImplementation of a high order function returns undefined

🐛 Bug Report
When mocking a high order function with mockImplementation, the mock returns undefined instead of the inner function.
// module.test.js

import foo from './module';
import { isKey } from './utils';

jest.mock('./utils');

test('', () => {
  isKey.mockImplementation(() => () => false);

  expect(foo('wew')).toBe(false);
})

// module.js

import { anyPass } from 'ramda';
import { isKey } from './utils';

console.log(isKey); // Mock function
console.log(isKey()); // undefined

const isValidKey = anyPass([isKey('Enter'), isKey('Backspace')]);

const foo = k => {
  return isValidKey(k);
}

export default foo;

This is the result of executing this test suite:
TypeError: Cannot read property 'apply' of undefined

      at node_modules/ramda/src/anyPass.js:44:22
      at foo (src/module.js:10:10)
      at Object.<anonymous>.test (src/module.test.js:9:31)
          at new Promise (<anonymous>)
          at <anonymous>

The problem is that inside module.js when calling isKey(), instead of returning the inner function () => false it returns undefined, and anyPass is trying to execute it as a function.
The weird thing is that if you transform the function isValidKey to a non-point-free style, it works as expected. isKey(...) evaluates to the expected function inside the scope of that function:
const isValidKey = k => anyPass([isKey('Enter'), isKey('Backspace')])(k);

To Reproduce
Clone and execute the test on this repo (it was created using create-react-app)
git clone git@github.com:nlucero/jest-mockimplementation-bug.git
npm i
npm run test

Expected behavior
Mock function should return the inner function instead of undefined.
Env info
System:
    OS: macOS High Sierra 10.13.5
    CPU: x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
  Binaries:
    Node: 8.11.1 - /usr/local/bin/node
    Yarn: 1.7.0 - /usr/local/bin/yarn
    npm: 6.1.0 - /usr/local/bin/npm

The weird thing is that if you transform the function isValidKey to a non-point-free style, it works as expected.

Yes. Because if you re-write the function that way, isKey is not used during module initialization. You are actually not defining a proper mock for isKey until after your first test, when the modules were already loaded by `jest.
Try mocking the whole of your utils module before running any test.
import foo from './module';
import { isKey } from './utils';

jest.mock('./utils', { isKey: jest.fn() });

test('', () => {
  isKey.mockImplementationOnce(() => () => false);

  expect(foo('wew')).toBe(false);
})

@nfantone You are right. At  module initialization, my mock is still not defined so it uses the default jest.fn().
AFAIK jest.mock('./utils', { isKey: jest.fn() }) is the same as jest.mock('./utils') (correct me if I'm wrong) so chaning that line doesn't change anything.
The question is then: How can I define a mock implementation at test level that is available at module initialization?

I'm closing this since this is more of a question/request for help than a bug.

Did you figure out how to solve it ?


thirdparty: use libevent 2.1.8

This fixes two tests. I believe they passed previously due to how event
loop exiting happens in libevent 2.1.

@lyft/network-team @htuch

+1


Update monitoring-OpenAPS.md

Add note for reason offline webpage may not load and fix for it.

The offline webpage does not appear at all if that line is not in crontab.
I'm on dev right now. Without that line I would get errors trying to access the site in browser, with the site will load. It will work with dev code but I'm not sure that I have the new style cron jobs.

Have you re-run oref0-setup since the 0.7.0-dev refactor?  If so, your crontab will just have a few lines, running oref0-cron-every-minute, oref0-cron-every-15min, oref0-cron-nightly, and oref0-cron-post-reboot. The latter has:
bin/oref0-cron-post-reboot.sh:    flask run -p 80 --host=<IP_ADDRESS> | tee -a /var/log/openaps/flask.log

I did re-run the interactive setup last week after pulling what was then the latest dev branch. However, I still have a 'old' style crontab with a dozen or so lines.

Do you remember whether you deleted and replaced your crontab when you did oref0-setup?

I did not manually delete it and the script didn't ask about cron setup.

Sounds like oref0-setup didn't complete successfully then.  It should always prompt to replace crontab at the end.  I'd suggest re-running it.

I did. This time it did ask about cron but it's still the old style

If you don't delete the old crontab, it'll keep the old lines and add the new ones as well.  You'll want to say Yes to deleting the old crontab and let it recreate it.

I did remove the existing crontab.

If you're getting old-style cron entries re-added after removing the existing crontab, then you haven't successfully installed the latest oref0 dev before running oref0-setup.  The dev oref0-setup code is now this: https://github.com/openaps/oref0/blob/dev/bin/oref0-setup.sh#L1359-L1396

The new style crontab works

Cool.  Do you know what the problem was that prevented you from getting a new-style crontab earlier?
Should we revise this PR to mention that as a better fix?  Or leave the docs as-is?


[contrib/terraform/openstack] Add nova availability zones

Add nova availability zones

Split resources between multiple availability zones (AZ). Many deployments
run across multiple AZ to scale and create smaller failure domains.
Resources are deployed in an as evenly distributed fashion possible across
all AZ listed in the availability_zone variable.

I like the idea, even with a single AZ cluster it's nice to be able to chose which AZ the cluster ends up into.

I guess this can be closed as https://github.com/kubernetes-incubator/kubespray/pull/3047 is merged.


Refactor parts of fast histogram utilities

I have made a few changes to the histogram utilities, mostly encapsulating functionality. This improves safety as it restricts direct access to pointers and provides a more defined interface to use the Column class.
I also added a few tests to check that the Column class was doing what I expected.
I am using this class as a part of a new experimental algorithm.
@hcho3 A question: There is code for packing smaller bin ranges into Column but this is not documented or used. Was this an experiment? Was it useful in the end?

@RAMitchell Yes, I toyed with the idea of packing small bins into Column, but in the end it didn't make much difference in performance. You can try using uint8_t or uint16_t with the (undocumented) parameter colmat_dtype.

Also I appreciate you taking time to read my old code. I wish I had time to get back to it but reality is such that I barely have time just to keep up with maintenance duty 😭

Would you be opposed to removing the bin packing/type switching? It is adding a fair amount of complexity that might be unnecessary.

I'll leave it to you to decide.
Ps. I had someone ask me if multi-GPU training increases amount of data that can be used. Does GPU hist partition the data over multiple GPUs or does the data get duplicated?

Data gets partitioned across GPUs, so more GPUs allows you to run bigger datasets.

Codecov Report

Merging #3564 into master will increase coverage by 2.15%.
The diff coverage is 61.94%.

@@             Coverage Diff              @@
##             master    #3564      +/-   ##
============================================
+ Coverage     45.89%   48.04%   +2.15%
  Complexity      188      188
============================================
  Files           168      169       +1
  Lines         13246    13345      +99
  Branches        428      457      +29
============================================
+ Hits           6079     6412     +333
+ Misses         6963     6708     -255
- Partials        204      225      +21

Impacted Files
Coverage Δ
Complexity Δ

src/tree/fast_hist_param.h
100% <ø> (ø)
0 <0> (ø)
:arrow_down:

tests/cpp/data/test_metainfo.cc
95.74% <ø> (-1.4%)
0 <0> (ø)

src/tree/updater_fast_hist.cc
1.36% <0%> (+0.02%)
0 <0> (ø)
:arrow_down:

tests/cpp/common/test_column_matrix.cc
100% <100%> (ø)
0 <0> (?)

src/common/hist_util.h
18.75% <100%> (+18.75%)
0 <0> (ø)
:arrow_down:

src/common/hist_util.cc
34.23% <45.45%> (+33.93%)
0 <0> (ø)
:arrow_down:

src/common/column_matrix.h
94.66% <86.66%> (+94.66%)
0 <0> (ø)
:arrow_down:

src/data/simple_csr_source.cc
85.91% <0%> (-12.68%)
0% <0%> (ø)

src/data/simple_dmatrix.h
84.61% <0%> (-7.7%)
0% <0%> (ø)

include/xgboost/data.h
90.21% <0%> (-2.34%)
0% <0%> (ø)

... and 17 more

Continue to review full report at Codecov.

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

@RAMitchell Should we include this in 0.80 release?

There should be no changes in behaviour for the end user. There is no need to include it but it probably won't hurt either.


Preview URLs without a port defined will fail

Referencing this line: https://github.com/craftcms/gatsby-helper/blob/a7febe59a99ef0e13f5bc2c1a9a69f641cf3ff53/src/Plugin.php#L162
If I supply a preview URL that doesn't have a port number — meaning I'm assuming port 80 as the default — then this check will fail.

I think there is also a mis-match in logic here with the code in line 176:
if ((doPreview || currentlyPreviewing) && (!doPreview || ("$compare" == compareUrl.protocol + '//' + compareUrl.host))) {
I think that there is no way for this to match if the port is included in the $compare string in line 162.

Gatsby Helper 1.0.0-beta.2 is out now with a fix for this.


Require the column with operation type

Induced by https://github.com/src-d/identity-matching/issues/90 - supporting incremental DB updates
Every Parquet file must always contain a boolean column named "op", True means insertion operation and False means deletion.

Closing the issue as It has been implemented in https://github.com/src-d/parquetry/pull/3


Puppeteer calls are 404ing

Hi,
As of this morning my calls using npx @puppeteer/browsers install chrome@stable result in a 404 error to the edgedl.me urls. Any one else seeing this issue? My scripts are all broken as I cannot get the latest CfT version.
Thanks.

I'm not a contributor and don't have more details on the problem, but we're having the same issue and all our CI is also now down due to this issue.
As a potential workaround that may work for some people's use cases, it appears that ironically enough, chrome for testing "stable" is down, but "dev" is still working, so we're currently putting emergency PRs through on all our projects to move from stable to dev as a workaround for the time being.

(https://github.com/GoogleChromeLabs/chrome-for-testing/pull/108#issue-2136148704)
not sure what's going on here but I changed the endpoint from the edgedl(which is legacy?) to the storage.googleapis and it did the trick for my selenium
zip_name = zip_name.replace("_", "-", 1)
# download_url = "https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/%s/%s/%s"
download_url = 'https://storage.googleapis.com/chrome-for-testing-public/%s/%s/%s'
download_url %= (self.version_full.vstring, self.platform_name, zip_name)

@mathiasbynens I'm also seeing 500 failures when downloading Puppeteer when trying to download any URL with the edgedl domain. We can't simply change to using the new download URL because other packages we depend on and install are still using the edgedl URL.
If this is the same ticket, what's the status of this ticket? This is pretty disruptive.

Since you asked, I’ll elaborate on the details: the final step in the abovementioned hosting solution migration is to set up redirects from the old base URL https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/* to the new location https://storage.googleapis.com/chrome-for-testing-public/*. This way, even old software that hardcodes the old base URL would still be able to get downloads for newer version numbers.

example of a URL that still 404s: https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/121.0.6167.184/linux64/chrome-linux64.zip

@mathiasbynens Is there an update on this issue? This is a major breaking change that is currently blocking any pipeline that uses the Chrome browser.
When I run npx @puppeteer/browsers install chrome@stable I still get a 404, we use this inside the pipeline to setup puppeteer inside the CI.
Error: Download failed: server returned code 404. URL: https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/124.0.6367.91/mac-arm64/chrome-mac-arm64.zip

Updating to the latest @puppeteer/browsers should address this, so I’m closing this issue.
More background: we’ve enabled server-side redirects multiple times now but every time there was unexpected breakage (incl. in Puppeteer itself at first). For this reason, we’ve disabled redirects for now, but we plan on taking another look in 2024Q3 in hopes we can re-enable redirects again (b/330111501).


[VS Project Templates] Add Support for Protobuf to Web API Projects

Adding support for protobuf.net to the Web API projects offers a more performant binary wire format

Similar to binary encoding for WCF projects

Deferred to a future version (post 2.5). Developer can always add the packages manually.

Closing this for now because there are currently some shortcomings in the Web API support for Protobuf, and the packages can always be added manually.


HEAD request using http/2 fails on bodies that don't implement is_end_stream

Trying to do a HEAD request on an http/2 server that uses response bodies that don't implement HttpBody::is_end_stream (so that it sometimes return true) fail with an http2 protocol error.
I noticed this while wrapping a hyper::Body but not passing though is_end_stream

@jeromegn have you seen other HTTP2 implementations returning an error because of this? Or only h2? If only Rust, then have you seen this issue since https://github.com/hyperium/h2/pull/490 was merged and released?
I worry that just because a Method doesn't normally have a body, it could still be allowed, and it might still send trailers anyways, so just curious if we don't need to fix this specifically.

Hmm, I've fixed the issue by properly passing through all methods to my wrapped Body (by re-implementing is_end_stream).
I don't believe I've encountered it since then.
Reading my initial issue, I'm a bit confused about some of the wording :sweat_smile:. I think this is only an hyper / h2 issue.


How to translate the cities?

Is your feature request related to a problem? Please describe.
I've this client using en/ar, they would love the cities to be translated to cities.
Describe the solution you'd like

It should be same like country (no brainer) just install and magically translated when we pass the locale
I think there will be another table to handle the translation, just need to store the locale you need
I imagine we have artisan like (php artisan world:translate --cities=ar), the output is generate to cities-locale

**Alternative

Perhaps just store the locale on file, just need good organized it

Additional context

I'm not sure where to retrieve the locale data, do you mind sharing the info

@sluxzer Excellent idea but do you have source for the translated cities files?


External relative paths are screwed up in build

Describe the bug
I have a relative script tag inside my <head> like this:
<script type="module" src="/../modules/module1"></script>

It is marked as being external via the rollup options. However, Vite moves this into the bundle and adjusts the path based on the file system of the build agent (e.g. import "./modules/module1"). But the path is obviously not relative to the file system but the URL.
I tried a lot but I can't prevent vite from messing with that script tag or make it understand that it's not relative to the current file system. I tried replicating it with rollup only but I can't so I assume it is a Vite issue.
Reproduction
https://stackblitz.com/edit/vitejs-vite-gvcugb?file=index.html
Steps to reproduce
Run npm i && npm run build, check dist/index.html and the first chars in dist/assets/*.js and see the relative path has been moved and altered.

I found out that something similar has existed before: https://github.com/vitejs/vite/issues/116. Also, there is this discussion about it: https://github.com/vitejs/vite/discussions/8724.
I also found the issue in the code: https://github.com/vitejs/vite/blob/main/packages/vite/src/node/plugins/html.ts#L370
Here it is marked for removal b/c the isExcluded does not query config.build.rollupOptions.external.


SLO1 performance issues

We are having SLO1 error budget issues.
These are mostly caused by db performance issues and we are working on them:

packit/packit-service#1908.

We are also planning further improvements:

packit/packit-service#1923
packit/packit-service#1940
packit/packit-service#1942
packit/packit-service#1943

Related to the research currently being worked on.

Recently several improvements regarding this were implemented: storing the package configuration in DB and not running private repo check for result events; so let's see how the situation will improve. If needed, we can implement also #1923 .