ForumChannel and Thread returning wrong ForumTags

Summary
ForumChannel and Thread returning wrong ForumTags
Reproduction Steps
Get Thread and ForumChannel in any way and try to get ForumTags from it
Minimal Reproducible Code
No response
Expected Results
Get actual ForumTags from forum channels
Actual Results
ForumChannel.available_tags only returns last one
Thread.applied_tags and Thread.applied_tag_ids will return empty list
Actually got all data from Discord according to logs, but can't access it in my code
Intents
all
System Information

Python v3.11.2-final
nextcord v2.4.1-final
aiohttp v3.8.4
system info: Windows 10 10.0.19044

Checklist

[X] I have searched the open issues for duplicates.
[X] I have shown the entire traceback, if possible.
[X] I have removed my token from display, if visible.

Additional Context
Found bugs in code:

ForumTag dict (ForumChannel._available_tags) has been generated with data["id"] instead of tag["id"] as keys which lead to only saving last loaded tag by wrong id. Must be int(tag["id"]): ForumTag.from_data(tag) for tag in data.get("available_tags", []):

https://github.com/nextcord/nextcord/blob/8a04ed3b4ca72b48d27e2af1ecfe380b9f8f32c1/nextcord/channel.py#L964

Key "applied_thread_tags" does not exist in thread data, which lead to losing all tags when getting Thread. Existing key -
"applied_tags". Must be int(tag_id) for tag_id in data.get("applied_tags", []):

https://github.com/nextcord/nextcord/blob/8a04ed3b4ca72b48d27e2af1ecfe380b9f8f32c1/nextcord/threads.py#L181
Pull-Request failed by Pyright for some reason, but fix is tested and works in 2.4.1

If you found bugs in the code, it would be helpful to open a PR to fix the issues.

If you found bugs in the code, it would be helpful to open a PR to fix the issues.

As I said, it failed checks for reason, which I am completely not responsible to. That "line 964" got None instead of Snowflake in payload when I haven't touched it in any way, just fixing a typo. Also those fixes discovered to be not enough to fully fix the issue, cuz even with them Thread.edit() function does not update ForumTags in cache

If you found bugs in the code, it would be helpful to open a PR to fix the issues.

As I said, it failed checks for reason, which I am completely not responsible to. That "line 964" got None instead of Snowflake in payload when I haven't touched it in any way, just fixing a typo. Also those fixes discovered to be not enough to fully fix the issue, cuz even with them Thread.edit() function does not update ForumTags in cache
Recreated PR again: #1021
 /home/runner/work/nextcord/nextcord/nextcord/channel.py:964:17 - error: Argument of type "Snowflake | None" cannot be assigned to parameter "__x" of type "ReadableBuffer | str | SupportsInt | SupportsIndex | SupportsTrunc" in function "__new__"
   Type "Snowflake | None" cannot be assigned to type "ReadableBuffer | str | SupportsInt | SupportsIndex | SupportsTrunc"
     Type "None" cannot be assigned to type "ReadableBuffer | str | SupportsInt | SupportsIndex | SupportsTrunc"
       Type "None" cannot be assigned to type "str"
       Type "None" cannot be assigned to type "ReadOnlyBuffer"
       Type "None" cannot be assigned to type "bytearray"
       Type "None" cannot be assigned to type "memoryview"
       Type "None" cannot be assigned to type "array[Any]"
       Type "None" cannot be assigned to type "mmap"
   ... (reportGeneralTypeIssues)
1 error, 0 warnings, 0 informations

I mentioned this a couple of times in the help thread
https://github.com/nextcord/nextcord/blob/8a04ed3b4ca72b48d27e2af1ecfe380b9f8f32c1/nextcord/types/channel.py#L154
This should not be optional, I'm not sure why it is.
From c886fdce4896f583806725b6136978004ebc6160 Mon Sep 17 00:00:00 2001
From: Oliver Wilkes<EMAIL_ADDRESS>Date: Sun, 26 Mar 2023 22:21:56 +0100
Subject: [PATCH] typing(types): make ForumTag.id not optional

---
 nextcord/types/channel.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nextcord/types/channel.py b/nextcord/types/channel.py
index 5f6ab52d..2b1974b8 100644
--- a/nextcord/types/channel.py
+++ b/nextcord/types/channel.py
@@ -151,7 +151,7 @@ class StageInstance(TypedDict):

 class ForumTag(TypedDict):
-    id: Optional[Snowflake]
+    id: Snowflake
     name: str
     moderated: bool
     emoji_id: NotRequired[Optional[Snowflake]]
--
2.37.2

Reopening since the underlying issue with the library hasn't been resolved yet.


Fix absence of filtering in CompileLoss when not built

Last August, I suggested a simple workaround to avoid duplicated filtering in CompileLoss when not built (PR #20161), stressing in the description that the root cause was that _filter_unused_inputs was modifying y_true/y_pred arguments in-place.
This PR suggests to undo the workaround, now that _filter_unused_inputs has been properly fixed in this commit to not modify y_true/y_pred in-place anymore (PR #20296).
Without this PR (in Keras 3.6.0), the necessary filtering does not occur anymore in CompileLoss when not built (the bug typically becomes apparent whenever y_pred is a dict with more keys than y_true/loss).

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

Project coverage is 57.42%. Comparing base (acceb5a) to head (c37660a).

:exclamation:  There is a different number of reports uploaded between BASE (acceb5a) and HEAD (c37660a). Click for more details.
HEAD has 6 uploads less than BASE

Flag
BASE (acceb5a)
HEAD (c37660a)

keras
4
1

keras-torch
1
0

keras-tensorflow
1
0

keras-jax
1
0

Additional details and impacted files
@@             Coverage Diff             @@
##           master   #20345       +/-   ##
===========================================
- Coverage   78.88%   57.42%   -21.46%
===========================================
  Files         512      512
  Lines       49250    49250
  Branches     7954     7954
===========================================
- Hits        38853    28284    -10569
- Misses       8539    19161    +10622
+ Partials     1858     1805       -53

Flag
Coverage Δ

keras
57.42% <100.00%> (-21.33%)
:arrow_down:

keras-jax
?

keras-numpy
57.42% <100.00%> (ø)

keras-tensorflow
?

keras-torch
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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


Cutting video successfully on window, but failed on ubuntu

Q
A

Bug?
Yes

New Feature?
no

Version Used
Specific tag or commit sha

FFmpeg Version
3.3.3

OS
Ubutu 16.10

Actual Behavior
PHP-FFMpeg cannot cut video on ubuntu.
Expected Behavior
PHP-FFMpeg can cut video on ubuntu. I got this log from laravel:
ffmpeg failed to execute command '/usr/bin/ffmpeg' '-y' '-i' '/var/www/calling/calling-twilio/storage/app/public/uploads/mat.mp4' '-ss' '00:00:02.00' '-t' '00:00:01.00' '-threads' '12' '-vcodec' 'libx264' '-acodec' 'libmp3lame' '-b:v' '1000k' '-refs' '6' '-coder' '1' '-sc_threshold' '40' '-flags' '+loop' '-me_range' '16' '-subq' '7' '-i_qfactor' '0.71' '-qcomp' '0.6' '-qdiff' '4' '-trellis' '1' '-b:a' '128k' '-pass' '1' 'output.mp4'
When i run above command on terminal. It worked correctly
Steps to Reproduce
My code:
$format = new FFMpeg\Format\Video\X264();
$format->setAudioCodec("libmp3lame");
$video = FFMpeg::fromDisk('public')->open('mat.mp4');
$video->filters()->clip(FFMpeg\Coordinate\TimeCode::fromSeconds(2), FFMpeg\Coordinate\TimeCode::fromSeconds(1));
$video->save($format, 'output.mp4');
I already set php-user have permission to execute ffmpeg on relative folders

Are there some more pieces of information from the error?


[AutoPR compute/resource-manager] RunCommands 2018-06-01

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/3422

(message created by the CI based on PR content)

Codecov Report

Merging #2935 into restapi_auto_compute/resource-manager will decrease coverage by 0.2%.
The diff coverage is 0%.

@@                            Coverage Diff                            @@
##           restapi_auto_compute/resource-manager    #2935      +/-   ##
=========================================================================
- Coverage                                  56.29%   56.09%   -0.21%
=========================================================================
  Files                                       8045     7918     -127
  Lines                                     165239   163733    -1506
=========================================================================
- Hits                                       93027    91851    -1176
+ Misses                                     72212    71882     -330

Impacted Files
Coverage Δ

...te/azure/mgmt/compute/compute_management_client.py
43.41% <0%> (-0.27%)
:arrow_down:

...cebus/azure/mgmt/servicebus/models/resource_py3.py
55.55% <0%> (-44.45%)
:arrow_down:

...ure/mgmt/servicebus/models/tracked_resource_py3.py
62.5% <0%> (-37.5%)
:arrow_down:

...ninsights/models/events_browser_timing_info_py3.py

...ationinsights/models/events_browser_timing_info.py

...azure/applicationinsights/models/error_info_py3.py

...tioninsights/models/events_exception_result_py3.py

azure-applicationinsights/azure/__init__.py

...ationinsights/models/events_custom_event_result.py

...cationinsights/models/events_exception_info_py3.py

... and 124 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 663e409...d366995. Read the comment docs.

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/2487


Dependencies [javax.sql.DataSource] are not provided - missing @Singleton, @Component, @Factory/@Bean or specify external dependency via @InjectModule requires attribute

version: 8.4
No dependency provided for javax.sql.DataSource on org.jdbi.v3.core.Jdbi
Dependencies [javax.sql.DataSource] are not provided - missing @Singleton, @Component, @Factory/@Bean or specify external dependency via @InjectModule requires attribute

code:
  @Bean(destroyMethod = "close")
  public HikariDataSource dataSource() {
    var c = config.getConfig("jdbc.ds");
    var hc = new HikariConfig();
    hc.setJdbcUrl(c.getString("jdbc-url"));
    hc.setUsername(c.getString("username"));
    hc.setPassword(c.getString("password"));
    hc.setDriverClassName(c.getString("driver-class-name"));
    hc.setMinimumIdle(c.getInt("min-idle"));
    hc.setMaximumPoolSize(c.getInt("max-pool-size"));
    hc.setConnectionTestQuery(c.getString("connection-test-query"));
    hc.setAutoCommit(false);
    return new HikariDataSource(hc);
  }

hello.
I need to register the data source and expect to automatically call the destruction function when the application stops.
However, the 'DataSource' interface has no destruction function, so I need to return the 'HikariDataSource' type here. However, functions that depend on 'DataSource' cannot use the interface type, and 'HikariDataSource' injection must also be adopted.

Can you show the generated code that registers the HikariDataSource ... the generated method with the
if (builder.isAddBeanFor(HikariDataSource.class, ...)) {
Can you show us that? What we see here are the name and types that the HikariDataSource bean is going to be registered for. We are looking to see if javax.sql.DataSource is there.

/**
 * Generated source - dependency injection builder for DbBeans.
 */
@Generated("io.avaje.inject.generator")
public class DbBeans$DI  {

  /**
   * Create and register HikariDataSource via factory bean method DbBeans#dataSource().
   */
  public static void build_dataSource(Builder builder) {
    if (builder.isAddBeanFor(HikariDataSource.class, HikariConfig.class, DataSource.class, CommonDataSource.class, Wrapper.class, HikariConfigMXBean.class)) {
      DbBeans factory = builder.get(DbBeans.class);
      HikariDataSource bean = factory.dataSource();
      HikariDataSource $bean = builder.register(bean);
      builder.addPreDestroy($bean::close);
    }
  }
}

Ok cool. I'm pretty sure I can reproduce the issue.
The meta data does not have "provides javax.sql.DataSource".  So the ordering of wiring isn't correct which gives us this error.  So I need to check if/why bean factory method isn't giving us the "provides" we expect in the meta data (which is used to control wiring order).

I have reproduced and have a fix.
In summary all the factory beans prior to this fix have missing / empty provides ... I'm not sure how we didn't hit this before really. Anyway, pushing the failing test and fix into a branch.


Tab Name

Add an icon and name property to world or sack to be display in the tab.

tab name is taken care of in #153


Upload functionality

Predecessors:

[ ] #4

Tasks:

[ ] Integrating dropzone.js (http://chrisbeaver.com/2014/09/using-dropzonejs-laravel-4/)
[ ] Configure frontend

[ ] Laravel view
[ ] frontend logic with dropzone.js

[ ] configure backend

[ ] laravel route
[ ] database caching of uploaded files

während dem hochladen, einzelne schritte (auch analyseschritte) mit angeben

[ ] move upload handling from routes to UploadController
[ ] correct handling when queue is completed
[ ] error handling


Feature request: return status code (and error msg)

In first of all many thanks for your work!
Currently if a Search Engine returns a non 200 code there is only a print message. It would be great if status code and error message would be accessible to detect bans (or other issues) by search engines.

I'm not sure if we need this feature, but I can help you implement it if you want. How do you think we should handle this? Maybe create a SearchEngine.last_response attribute?

SearchEngine.last_response would be a good option. If I'm not wrong there is already in engine.py the _is_ok function which returns True/False and  print a message, maybe it is possible to extend this one to return/store the status code, this would be already very helpful. I'm also using MultipleSearchEngines class  and want in optimal case understand which of the engines banned me.
For me this feature is important because my search queries are very specific, so I often get empty results and I need to distinguish this from a ban.
I could change the code my self, but the I will most likely get merge conflicts when pulling later new code version from your repository.

I added a SearchEngine.is_banned  boolean attribute, with default value false that changes to true if the status code is 403, 429 or 503. Ban detection happens in SearchEngine._is_ok(), as you suggested; it makes good sense and it's easy to override. Also added a MultipleSearchEngines.banned_engines list that stores the names of banned engines. Thanks for your suggestions, looking forward to hearing your feedback.

Many thanks!


[Errno 99] Cannot assign requested address

Trying to migrate from a working setup of https://github.com/porkbundomains/porkbun-dynamic-dns-python and am seeing the container stuck in a constant restarting loop.
Current docker compose is
services:
  porkbun-ddns:
    image: "mietzen/porkbun-ddns:latest"
    container_name: porkbun-ddns
    environment:
      DOMAIN: "<redacted>.com" # Your Porkbun domain
      SUBDOMAINS: "adguard,jellyfin,deemix" # Subdomains comma spreaded
      SECRETAPIKEY: "<redacted>" # Your Porkbun Secret-API-Key
      APIKEY: "<redacted>" # Your Porkbun API-Key
    restart: unless-stopped

Which results in the following looping restart error:
2023-11-29 21:46:12 Traceback (most recent call last):
2023-11-29 21:46:12   File "/entrypoint.py", line 51, in <module>
2023-11-29 21:46:12     porkbun_ddns.update_records()
2023-11-29 21:46:12   File "/usr/local/lib/python3.12/site-packages/porkbun_ddns-0.4.1-py3.12.egg/porkbun_ddns/porkbun_ddns.py", line 135, in update_records
2023-11-29 21:46:12   File "/usr/local/lib/python3.12/site-packages/porkbun_ddns-0.4.1-py3.12.egg/porkbun_ddns/porkbun_ddns.py", line 90, in get_public_ips
2023-11-29 21:46:12   File "/usr/local/lib/python3.12/urllib/request.py", line 215, in urlopen
2023-11-29 21:46:12     return opener.open(url, data, timeout)
2023-11-29 21:46:12            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-29 21:46:12   File "/usr/local/lib/python3.12/urllib/request.py", line 515, in open
2023-11-29 21:46:12     response = self._open(req, data)
2023-11-29 21:46:12                ^^^^^^^^^^^^^^^^^^^^^
2023-11-29 21:46:12   File "/usr/local/lib/python3.12/urllib/request.py", line 532, in _open
2023-11-29 21:46:12     result = self._call_chain(self.handle_open, protocol, protocol +
2023-11-29 21:46:12              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-29 21:46:12   File "/usr/local/lib/python3.12/urllib/request.py", line 492, in _call_chain
2023-11-29 21:46:12     result = func(*args)
2023-11-29 21:46:12              ^^^^^^^^^^^
2023-11-29 21:46:12   File "/usr/local/lib/python3.12/urllib/request.py", line 1392, in https_open
2023-11-29 21:46:12     return self.do_open(http.client.HTTPSConnection, req,
2023-11-29 21:46:12            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-29 21:46:12   File "/usr/local/lib/python3.12/urllib/request.py", line 1347, in do_open
2023-11-29 21:46:12     raise URLError(err)
2023-11-29 21:46:12 urllib.error.URLError: <urlopen error [Errno 99] Cannot assign requested address>
2023-11-29 21:47:13 Traceback (most recent call last):
2023-11-29 21:47:13   File "/usr/local/lib/python3.12/urllib/request.py", line 1344, in do_open
2023-11-29 21:47:13     h.request(req.get_method(), req.selector, req.data, headers,
2023-11-29 21:47:13   File "/usr/local/lib/python3.12/http/client.py", line 1319, in request
2023-11-29 21:47:13     self._send_request(method, url, body, headers, encode_chunked)
2023-11-29 21:47:13   File "/usr/local/lib/python3.12/http/client.py", line 1365, in _send_request
2023-11-29 21:47:13     self.endheaders(body, encode_chunked=encode_chunked)
2023-11-29 21:47:13   File "/usr/local/lib/python3.12/http/client.py", line 1314, in endheaders
2023-11-29 21:47:13     self._send_output(message_body, encode_chunked=encode_chunked)
2023-11-29 21:47:13   File "/usr/local/lib/python3.12/http/client.py", line 1074, in _send_output
2023-11-29 21:47:13     self.send(msg)
2023-11-29 21:47:13   File "/usr/local/lib/python3.12/http/client.py", line 1018, in send
2023-11-29 21:47:13     self.connect()
2023-11-29 21:47:13   File "/usr/local/lib/python3.12/http/client.py", line 1453, in connect
2023-11-29 21:47:13     super().connect()
2023-11-29 21:47:13   File "/usr/local/lib/python3.12/http/client.py", line 984, in connect
2023-11-29 21:47:13     self.sock = self._create_connection(
2023-11-29 21:47:13                 ^^^^^^^^^^^^^^^^^^^^^^^^
2023-11-29 21:47:13   File "/usr/local/lib/python3.12/socket.py", line 852, in create_connection
2023-11-29 21:47:13     raise exceptions[0]
2023-11-29 21:47:13   File "/usr/local/lib/python3.12/socket.py", line 837, in create_connection
2023-11-29 21:47:13     sock.connect(sa)
2023-11-29 21:47:13 OSError: [Errno 99] Cannot assign requested address
2023-11-29 21:47:13
2023-11-29 21:47:13 During handling of the above exception, another exception occurred:

Ahh, interesting. I assumed since those were commented out that they were optional.

I just merged and released the changes: https://github.com/mietzen/porkbun-ddns/releases/tag/v0.5.0, it's currently building the images.


Brain extraction workflow does not reuse cache

While testing FreeSurfer, two immediately succeeding runs with the same working directory rerun large chunks of the brain extraction workflow, due to an "outdated cache" detected for init_aff. This task had previously run successfully.
191011-18:12:31,369 nipype.workflow INFO:
	 [Node] Outdated cache found for "smriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.init_aff".
191011-18:12:31,901 nipype.utils INFO:
	 Running nipype version 1.2.3 (latest: 1.2.3)
191011-18:12:33,297 nipype.workflow INFO:
	 [MultiProc] Running 1 tasks, and 1 jobs ready. Free memory (GB): 13.77/13.97, Free processors: 1/8.
                     Currently running:
                       * smriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.init_aff
191011-18:12:34,337 nipype.workflow INFO:
	 [Node] Setting-up "smriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.init_aff" in "/scratch/smriprep_wf/single_subject_01_wf/anat_preproc_wf/brain_extraction_wf/init_aff".
191011-18:12:34,338 nipype.workflow INFO:
	 [Node] Outdated cache found for "smriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.init_aff".
191011-18:12:34,341 nipype.workflow INFO:
	 [Node] Running "init_aff" ("niworkflows.interfaces.ants.AI"), a CommandLine Interface with command:
antsAI -c [10,0.000001,10] -d 3 -x /home/smriprep/.cache/templateflow/tpl-OASIS30ANTs/tpl-OASIS30ANTs_res-01_desc-BrainCerebellumExtraction_mask.nii.gz -m Mattes[/scratch/smriprep_wf/single_subject_01_wf/anat_preproc_wf/brain_extraction_wf/res_tmpl/tpl-OASIS30ANTs_res-01_T1w_resampled.nii.gz,/scratch/smriprep_wf/single_subject_01_wf/anat_preproc_wf/brain_extraction_wf/res_target/sub-01_T1w_maths_corrected_resampled.nii.gz,32,Regular,0.250000] -o initialization.mat -p 0 -s [15.000000,0.100000] -t Affine[0.100000] -v 1
191011-18:12:37,280 nipype.workflow INFO:
	 [Node] Finished "smriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.init_aff".
191011-18:12:37,301 nipype.workflow INFO:
	 [Job 21] Completed (smriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.init_aff).
191011-18:12:37,303 nipype.workflow INFO:
	 [MultiProc] Running 0 tasks, and 2 jobs ready. Free memory (GB): 13.97/13.97, Free processors: 8/8.
191011-18:12:37,365 nipype.workflow INFO:
	 [Node] Outdated cache found for "smriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.norm".

I believe this is a result of not using the content hash, since nipype was patched too recently (https://github.com/nipy/nipype/pull/3072)

But I'm running with the same version of nipype...

What do you find below the last line ( [Node] Outdated cache found for "smriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.norm")? The diff between inputs should be shown.

I don't think it was. But I showed the first outdated cache on the first line. Anyway, not at that computer now. Can try rerunning on Monday.

Oh I see, yes - you'll need to increase the verbosity to see the inputs that changed.

Ah, the issue is that the brain extraction mask isn't pre-downloaded into the Docker image, so the timestamp hash is new every time.

Sorry, I wasn't clear before - we set the hash to content and write it to the config file, but then the config file is ignored because of that bug in nipype, I guess

Wait, you want to do content hashes in general? Isn't that going to take a very long time?

We've been doing it for a while in fMRIPrep and it doesn't seem to be a lot slower. Regardless, I agree that mask should be cached.

I'm adding it to #117.


Restangular.copy not copying arrays inside restangular object

I have a restangular object, which has an array of more restangular objects.
console.log(originalData); // displays the object correctly.
var data = Restangular.copy(originalData);
console.log(data); // the main object is copied ok, but the children restangular objects in an array are not coppied, but are empty/defallt restangular objects.
The original object has a structure like this:
originalData.services[0].name; // name is ok
data.services[0].name // undefined
Can you help me solve this issue? Should I maybe not use the regular array to store subitems (services) and use something else? Thanks!

Any update on this? @tomazahlin

Unfortunately not. I am not working on a "restangular" project anymore.

Okay I'll close this then.


ACME: allow configuration of time before certificate expiration to renew

What does this PR do?
Before this PR, when there were less than 30 days remaining before an ACME-obtained certificate expired, Traefik would attempt to renew it automatically. Now that value of 30 days is configurable (but it's still the default value). This setting is per certResolver. The new setting is called renewBeforeExpiry.
Also, Traefik would perform this check every 24 hours. That interval was reduced to once every hour per certificate.
Closes #8042
Motivation
This is useful when using an ACME server that issues short-lived certificates (e.g. 24 hours).
More

[x] Added/updated tests
[x] Added/updated documentation

Additional Notes

Hello @pmontepagano,
The Traefik team has reviewed this PR, and we think that the feature is a good one. We would like to see a small improvement before we will fully accept it though. We think that the renewal check frequency should also be configurable. Right now, your PR changes the hardcoded 24 hour check frequency to 1 hour, but that period should be configurable: (https://github.com/traefik/traefik/pull/8046/files#diff-4f93ba21a09614847c01e2f916eba5dcc78e000cb9c076900dc033aa5d2bfc58R194)
This would allow use with acme-based services that use short term certificates to be supported, by allowing the renewal window and the check frequency to both be reduced.
Thanks!

@dtomcej thanks for the feedback!
I just added the setting expirationCheckInterval, that lets you choose the frequency in which Traefik will check if an ACME certificate is due for renewal. By default it's once every hour.

Hello @pmontepagano,
I would suggest a new commit. We have a bot that ultimately squashes all commits on merge anyways, so there isn't any reason for you to do more work on old commits :)

After more research, and thanks to @ldez,
it seems that time.Duration is inapropriate to configure a certificate as its lower duration is a nanosecond.
To solve this, we have two options:
We could either use a types.Duration from Paerser where the default unit is the second.
Or we could, as @pmontepagano did, use an appropriate timescale, like the hour, and provide an integer to configure this duration.
Another point is that we might not need a ExpirationCheckInterval option as it can be directly calculated.
We tend to think that using types.Duration for RenewBeforeExpiry is better, and we could find a way to calculate ExpirationCheckInterval.
WDYT ?

I'm sorry for the delay.
Your comments made me think about it from another angle. I checked how certmagic handles this, and they do the following. They expose two settings (relevant to this pull request):

RenewCheckInterval: equivalent to this PR's ExpirationCheckInterval of type time.duration, by default 10 * time.Minute
RenewalWindowRatio: defines how much of a certificate's lifetime becomes the renewal window. The renewal window is the span of time at the end of the certificate's validity period in which it should be renewed. It's a float64 which by defaut is 1.0 / 3.0. The func currentlyInRenewalWindow determines if a certificate is in that renewal window.

I believe this solution is quite elegant, because it works well both for Let's Encrypt (30 days out if total 90 days lifetime) and for a 24 hour cert (renewal window would be the last 8 hours).
If you agree, I can change this PR to have this behaviour, even renaming both settings so that they are the same as certmagic's. Although, RenewCheckInterval should maybe be kept with 24 * time.Hour as the default value, to retain previous behaviour (and because we don't do any kind of rate limiting).

Given that v2.5.0-rc2 is already published, I'm guessing that since this is a new feature, if it gets merged, it will be included in v2.6.0, right? O does it have a chance of getting into v2.5.x ?

Hello @pmontepagano,
Sorry for the late reply.
First of all, Yes, this feature will be present in the next release after this PR' merge.
Secondly, for the feature: unlike Traefik, certmagic is a library that needs to allow full access to developers.
Traefik tries to simplify the user's configuration to help build a simpler one. It is preferable to "hide" configuration from the user as much as possible.
Therefore, ExpirationCheckInterval (or RenewCheckInterval that is the same behaviour) should be calculated.
Lastly, It seems that this feature could be done without RenewBeforeExpiry (or RenewalWindowRatio which is the same behaviour, and RenewBeforeExpiry might be clearer for the user).
It could be done with a non-linear function that matches the certificate duration with defined lengths, like this:

Certificate Duration
Calculated RenewBeforeExpiry
Calculated ExpirationCheckInterval

1 year
2 months
1 week

90 days
30 days
1 day

7 days
1 day
1 hour

24 hours
6 hours
10 min

...
...
...

WDYT about the last part?


Make JsonSupport visible

Bug in 0.3.0 and below. JsonSupport's available as a getter on the client but the interface itself is package private. 😷

fixed in https://github.com/zalando-incubator/nakadi-java/pull/74


Change MuID segmentation code in all methods where it was swapped

As I mentioned at the end of:
https://indico.fnal.gov/event/60550/contributions/271414/attachments/168773/226213/ndgar_11.07.23_caf_pid_update.pdf
there was a small bug affecting the position of the MuID reco hits. That could be seen when computing the distance between a reco hit and the corresponding sim hit (matched using the CellID).
I think the problem was that the order of the segmentation direction in the MuID strips was interchanged in some methods. It looks like after changing that the distance distributions start looking fine. 2D distributions (layer no vs distance) with the before and after can be found in slide 12.

Looks fine.  Thanks, Francisco!

Great! Thanks Tom for reviewing it so quickly.


Tickets/sitcom 945

Renamed the first draft.  It is ready for review.

I have made the changes Petr requested, merged the changes into the main branch, and deleted the ticket branch.


Upgrade junit-platform-launcher

Addresses https://github.com/junit-team/junit5/issues/2028
Context
The current version of junit-platform-launcher may skip tests if an exception is thrown during discovery. It's relatively easy to miss the warning log, especially when tests are run in CI.
Contributor Checklist

[x] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[x] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[x] Provide unit tests (under <subproject>/src/test) to verify logic
[x] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[x] Ensure that tests pass locally: ./gradlew <changed-subproject>:check

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in release notes

Thanks @pkoenig10 for the PR and sorry for taking so long to get back to you. Do you happen to have a good approach for integration testing the bug you refer to? I'd love to have an integration test showing that the upgrade indeed fixes the problem as it may depend on how Gradle uses the launcher. I've tried a few things with older versions of junit-platform but could not get it to silently ignore the errors. Happy to help with the test if we have an idea how to reproduce it from the outside (maybe @marcphilipp remembers a specific scenario).
Other than that, we need to rebase the PR and remove the old checksums from the dependency-verification.xml. Please let me know if you currently have the bandwidth to continue working on this.

I'd write a test with a custom TestEngine that throws an exception from its 'discover()` method and check that it gets included in the test report appropriately.

@pkoenig10 thanks for the fix, I've added tests and fixed the verification metadata. I've done this in a separate PR #12489 but cherry-picked your commit into it so you get the credit :)


bug?

https://github.com/chill117/proxy-lists/blob/2c34b37755b5572dee0cd2e3ba101b94d7200785/index.js#L169
did you mean filter.include  and filter.exclude ?

Yes :)
This has been fixed by this commit


Add "Hide uncraftable" checkbox to UI

Hides uncraftable items from both item browser and search. Satisfies Issue 22

This assumes uncraftable to be a craftable depth of 0, unless it spawns naturally.
Some screenshots:
Show uncraftable browser:

Hide uncraftable browser:

Show uncraftable search:

Hide uncraftable search:

I should note that I used Vue 2's eventBus, which is gone in Vue 3. It was by far the easiest way to make this work though; other methods fell short one way or another.

@mtklass if you could please rebase and resolve conflicts.

On it -- testing rebased changes now.

@connorhsm Ready to go!


feat: remove unneeded pipeline files, add publish, test pipelines

Remove publishing pipeline as this is the base repository. The existing fhir-works repository set-up should work with this repo - https://github.com/AscentMS/terragrunt_modules/blob/master/pipelines/fhir_works/buildspec.yml. I tried running the cdk diff with the same flags which worked.

You've re-opened this one. Did you intend on doing that?


[improve][broker][PIP-318] Support not retaining null-key message during topic compaction

PIP: #21541

Motivation
Implement #21541
Modifications

Add config topicCompactionRemainNullKey in the broker.conf, the default value is false.
If not retaining null-key message, add an empty single message placeholder to result when rebatching the message.
If the message with null-key, then add a null-key value to the result list of extractIdsAndKeysAndSize and record the delete event.

Verifying this change

[x] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

Matching PR in forked repository
PR in forked repository:

Codecov Report

Merging #21578 (1ca9ce5) into master (44abba9) will increase coverage by 0.02%.
Report is 20 commits behind head on master.
The diff coverage is 87.50%.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #21578      +/-   ##
============================================
+ Coverage     73.27%   73.29%   +0.02%
- Complexity    32676    32705      +29
============================================
  Files          1892     1892
  Lines        140632   140721      +89
  Branches      15467    15489      +22
============================================
+ Hits         103044   103146     +102
+ Misses        29497    29470      -27
- Partials       8091     8105      +14

Flag
Coverage Δ

inttests
24.11% <12.50%> (-0.24%)
:arrow_down:

systests
24.68% <12.50%> (-0.29%)
:arrow_down:

unittests
72.57% <87.50%> (+0.02%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files
Coverage Δ

...org/apache/pulsar/broker/ServiceConfiguration.java
99.38% <100.00%> (+<0.01%)
:arrow_up:

...g/apache/pulsar/client/impl/RawBatchConverter.java
93.75% <87.50%> (+0.24%)
:arrow_up:

...rg/apache/pulsar/compaction/TwoPhaseCompactor.java
73.83% <85.71%> (-4.24%)
:arrow_down:

... and 99 files with indirect coverage changes


Errno::ENOENT: No such file or directory

Bug report
Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to Homebrew again.

[x] ran brew update and can still reproduce the problem?
[x] ran brew doctor, fixed all issues and can still reproduce the problem?
[x] ran brew config and brew doctor and included their output with your issue?

What you were trying to do (and why)
brew install rothgar/tap/k
What happened (include command output)

Command output

brew install rothgar/tap/k
==> Installing k from rothgar/tap
==> Downloading https://github.com/rothgar/k/releases/download/0.1.0/k_0.1.0_Linux_x86_64.tar.gz
==> Downloading from https://github-production-release-asset-2e65be.s3.amazonaws.com/290982267/ace4cb00-e8c8-11ea-860a-917c7ee86515?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200828%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=2020
######################################################################## 100.0%
Error: An exception occurred within a child process:
  Errno::ENOENT: No such file or directory - k

What you expected to happen
k binary would be installed from https://github.com/rothgar/homebrew-tap
Step-by-step reproduction instructions (by running brew commands)
brew install rothgar/tap/k
Output of brew config and brew doctor commands

$ brew doctor
Your system is ready to brew.

$ brew config
HOMEBREW_VERSION: 2.4.14-18-g49fa3cc
ORIGIN: https://github.com/Homebrew/brew
HEAD: 49fa3cc75d89514c55eb5d87c4e9db6510911a47
Last commit: 2 hours ago
Core tap ORIGIN: https://github.com/Homebrew/linuxbrew-core
Core tap HEAD: 1230c76dbf1e2e6f0bd5ef4cd650189b7db0da48
Core tap last commit: 2 days ago
Core tap branch: master
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: :0
HOMEBREW_EDITOR: vim
HOMEBREW_MAKE_JOBS: 8
CPU: octa-core 64-bit skylake
Homebrew Ruby: 2.6.3 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/bin/ruby
Clang: N/A
Git: 2.17.1 => /usr/bin/git
Curl: 7.58.0 => /usr/bin/curl
Kernel: Linux 5.3.0-28-generic x86_64 GNU/Linux
OS: Ubuntu 18.04.5 LTS (bionic)
Host glibc: 2.27
/usr/bin/gcc: 7.5.0
glibc: N/A
gcc: N/A
xorg: N/A

I also ran with --debug and when the error happens I can see the /tmp/k-* directory is created and has files in it
$ exa -T /tmp/k-20200828-31562-1mvlnnx
/tmp/k-20200828-31562-1mvlnnx
├── bin
│  └── k
├── LICENSE
└── README.md

But I still receive the error
tar xof /home/rothgar/.cache/Homebrew/downloads/d03e53f2fac3fe09a4ed18bb9fbcb40f356b973cbb5f93a91fff12725f1cd79a--k_0.1.0_Linux_x86_64.tar.gz -C /tmp/d20200828-31562-1ev22a5
cp -pR /tmp/d20200828-31562-1ev22a5/README.md /tmp/k-20200828-31562-1mvlnnx/README.md
cp -pR /tmp/d20200828-31562-1ev22a5/LICENSE /tmp/k-20200828-31562-1mvlnnx/LICENSE
cp -pR /tmp/d20200828-31562-1ev22a5/bin/. /tmp/k-20200828-31562-1mvlnnx/bin
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/debrew.rb:17:in `raise'
Errno::ENOENT: No such file or directory - k
1. raise
2. ignore
3. backtrace
4. irb
5. shell

This is an issue with your custom formula.

The formula is generated via goreleaser which I have used successfully in multiple other projects.
The archive is downloaded and extracted properly and the binary file exists on disk. Is there something else that could be wrong with the formula or more debug information I can get as to why debrew.rb doesn't see the file on disk?

You are trying to install k but your file is located at bin/k.

Thank you! I updated the formula


vue版本tree默认展开所有节点不生效问题解决办法

[ ] I'm sure this does not appear in the issue list of the repository

Basic Info

Package Name And Version<EMAIL_ADDRESS>Browser: chrome<IP_ADDRESS>

Extra info
a-tree上加v-if 有数据的时候再让节点dom渲染

if the data reuqeste from server , you may have this question. add 'v-if' on the 'a-tree' tag

Repeat: #1610


INFO  [main] 2023-06-08 07:05:51,643 Keyspace.java:386 - Creating replication strategy system_traces params KeyspaceParams{durable_writes=true, replication=ReplicationParams{class=org.apache.cassandra.locator.NetworkTopologyStrategy, dc1=3}}
INFO  [main] 2023-06-08 07:05:51,643 NetworkTopologyStrategy.java:88 - Configured datacenter replicas are dc1:rf(3)
INFO  [main] 2023-06-08 07:05:51,644 ColumnFamilyStore.java:385 - Initializing system_traces.events
INFO  [main] 2023-06-08 07:05:51,647 ColumnFamilyStore.java:385 - Initializing system_traces.sessions
INFO  [main] 2023-06-08 07:05:51,658 AutoSavingCache.java:177 - Completed loading (8 ms; 10 keys) KeyCache cache
INFO  [main] 2023-06-08 07:05:51,675 CommitLog.java:173 - Replaying /opt/cassandra/data/commitlog/CommitLog-7-1686206905512.log
WARN  [main] 2023-06-08 07:05:51,685 CommitLogReplayer.java:305 - Origin of 3 sstables is unknown or doesn't match the local node; commitLogIntervals for them were ignored
INFO  [main] 2023-06-08 07:05:51,693 CommitLogReader.java:256 - Finished reading /opt/cassandra/data/commitlog/CommitLog-7-1686206905512.log
INFO  [main] 2023-06-08 07:05:51,696 CommitLog.java:175 - Log replay complete, 0 replayed mutations
INFO  [main] 2023-06-08 07:05:51,696 StorageService.java:837 - Populating token metadata from system tables
INFO  [main] 2023-06-08 07:05:51,701 StorageService.java:831 - Token metadata: Normal Tokens:
/<IP_ADDRESS>:7000:[-8941284778233163419, -8276776076055905344, -7614644569753664108, -6552292170083312568, -5414165630693417576, -3582249901738334892, -2867954437340673899, -1750715986468976306,<PHONE_NUMBER>220589833,<PHONE_NUMBER>224853884,<PHONE_NUMBER>697988007,<PHONE_NUMBER>091476671,<PHONE_NUMBER>447153379,<PHONE_NUMBER>368094215,<PHONE_NUMBER>058142773,<PHONE_NUMBER>738274926]
/<IP_ADDRESS>:7000:[-7996355661445742154, -6924855045105709341, -5907003640363282325, -5089331707750931531, -4013575826525351991, -3277660133814458350, -2198287326366856693, -954767320686264720,<PHONE_NUMBER>2270778,<PHONE_NUMBER>906169416,<PHONE_NUMBER>603212713,<PHONE_NUMBER>119326789,<PHONE_NUMBER>942913917,<PHONE_NUMBER>177852206,<PHONE_NUMBER>870064465,<PHONE_NUMBER>361226223]
/<IP_ADDRESS>:7000:[-8636795220687195110, -7378374629543542076, -6314033639770478679, -4494029338790532280, -2616965009277546251, -1448010086098531872, -398886285769340784,<PHONE_NUMBER>22174635,<PHONE_NUMBER>93814515,<PHONE_NUMBER>265795660,<PHONE_NUMBER>614508451,<PHONE_NUMBER>559951539,<PHONE_NUMBER>235355906,<PHONE_NUMBER>516485296,<PHONE_NUMBER>091163179,<PHONE_NUMBER>020121396]
/<IP_ADDRESS>:7000:[-8789039999460179265, -7151614837324625709, -5660584635528349951, -4791680523270731906, -3797912864131843442, -2407626167822201472, -1201388703392398296, -193144681688535003,<PHONE_NUMBER>07222706,<PHONE_NUMBER>407202174,<PHONE_NUMBER>085982538,<PHONE_NUMBER>440152055,<PHONE_NUMBER>605401730,<PHONE_NUMBER>875920601,<PHONE_NUMBER>195033648,<PHONE_NUMBER>804169695]
INFO  [main] 2023-06-08 07:05:51,761 ColumnFamilyStore.java:2252 - Truncating system.size_estimates
INFO  [main] 2023-06-08 07:05:51,790 ColumnFamilyStore.java:2289 - Truncating system.size_estimates with truncatedAt=1686207951768
INFO  [main] 2023-06-08 07:05:51,798 ColumnFamilyStore.java:878 - Enqueuing flush of local: 2.205KiB (0%) on-heap, 0.000KiB (0%) off-heap
INFO  [PerDiskMemtableFlushWriter_0:1] 2023-06-08 07:05:51,831 Memtable.java:469 - Writing Memtable-local@2040137849(0.431KiB serialized bytes, 3 ops, 0%/0% of on/off-heap limit), flushed range = (min(-9223372036854775808), max(9223372036854775807)]
INFO  [PerDiskMemtableFlushWriter_0:1] 2023-06-08 07:05:51,832 Memtable.java:498 - Completed flushing /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-8-big-Data.db (0.226KiB) for commitlog position CommitLogPosition(segmentId=1686207949124, position=31193)
INFO  [MemtableFlushWriter:2] 2023-06-08 07:05:51,860 LogTransaction.java:240 - Unfinished transaction log, deleting /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb_txn_flush_e7598380-05ca-11ee-89ed-bd5ee214825f.log
INFO  [main] 2023-06-08 07:05:51,886 ColumnFamilyStore.java:2316 - Truncate of system.size_estimates is complete
INFO  [main] 2023-06-08 07:05:51,886 ColumnFamilyStore.java:2252 - Truncating system.table_estimates
INFO  [main] 2023-06-08 07:05:51,887 ColumnFamilyStore.java:2289 - Truncating system.table_estimates with truncatedAt=1686207951887
INFO  [main] 2023-06-08 07:05:51,889 ColumnFamilyStore.java:878 - Enqueuing flush of local: 0.576KiB (0%) on-heap, 0.000KiB (0%) off-heap
INFO  [PerDiskMemtableFlushWriter_0:2] 2023-06-08 07:05:51,894 Memtable.java:469 - Writing Memtable-local@1583644326(0.091KiB serialized bytes, 1 ops, 0%/0% of on/off-heap limit), flushed range = (min(-9223372036854775808), max(9223372036854775807)]
INFO  [PerDiskMemtableFlushWriter_0:2] 2023-06-08 07:05:51,895 Memtable.java:498 - Completed flushing /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-9-big-Data.db (0.063KiB) for commitlog position CommitLogPosition(segmentId=1686207949124, position=31304)
INFO  [MemtableFlushWriter:2] 2023-06-08 07:05:51,908 LogTransaction.java:240 - Unfinished transaction log, deleting /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb_txn_flush_e7671810-05ca-11ee-89ed-bd5ee214825f.log
INFO  [main] 2023-06-08 07:05:51,914 ColumnFamilyStore.java:2316 - Truncate of system.table_estimates is complete
INFO  [main] 2023-06-08 07:05:51,917 QueryProcessor.java:167 - Preloaded 0 prepared statements
INFO  [main] 2023-06-08 07:05:51,917 StorageService.java:735 - Cassandra version: 4.0.3
INFO  [main] 2023-06-08 07:05:51,917 StorageService.java:736 - CQL version: 3.4.5
INFO  [main] 2023-06-08 07:05:51,917 StorageService.java:737 - Native protocol supported versions: 3/v3, 4/v4, 5/v5, 6/v6-beta (default: 5/v5)
INFO  [main] 2023-06-08 07:05:51,945 IndexSummaryManager.java:84 - Initializing index summary manager with a memory pool size of 51 MB and a resize interval of 60 minutes
INFO  [main] 2023-06-08 07:05:51,946 StorageService.java:754 - Loading persisted ring state
INFO  [main] 2023-06-08 07:05:51,946 StorageService.java:837 - Populating token metadata from system tables
INFO  [GossipStage:1] 2023-06-08 07:05:51,957 Gossiper.java:1969 - Adding /<IP_ADDRESS>:7000 as there was no previous epState; new state is EndpointState: HeartBeatState = HeartBeat: generation = 0, version = -1, AppStateMap = {}
INFO  [GossipStage:1] 2023-06-08 07:05:51,958 Gossiper.java:1969 - Adding /<IP_ADDRESS>:7000 as there was no previous epState; new state is EndpointState: HeartBeatState = HeartBeat: generation = 0, version = -1, AppStateMap = {}
INFO  [GossipStage:1] 2023-06-08 07:05:51,958 Gossiper.java:1969 - Adding /<IP_ADDRESS>:7000 as there was no previous epState; new state is EndpointState: HeartBeatState = HeartBeat: generation = 0, version = -1, AppStateMap = {}
INFO  [main] 2023-06-08 07:05:52,216 InboundConnectionInitiator.java:127 - Listening on address: (/<IP_ADDRESS>:7000), nic: eth0, encryption: unencrypted
WARN  [main] 2023-06-08 07:05:52,282 K8SeedProvider4x.java:58 - Seed provider couldn't lookup host kiran1-cassandra-int-dc1-additional-seed-service
WARN  [main] 2023-06-08 07:05:52,286 K8SeedProvider4x.java:58 - Seed provider couldn't lookup host kiran1-cassandra-int-dc1-additional-seed-service
INFO  [Messaging-EventLoop-3-6] 2023-06-08 07:05:52,372 OutboundConnection.java:1150 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:39114)->kiran1-cassandra-int-seed-service/<IP_ADDRESS>:7000-URGENT_MESSAGES-9123e845 successfully connected, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-3] 2023-06-08 07:05:52,372 OutboundConnection.java:1150 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:47448)->kiran1-cassandra-int-seed-service/<IP_ADDRESS>:7000-URGENT_MESSAGES-c0033dbb successfully connected, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-9] 2023-06-08 07:05:52,372 OutboundConnection.java:1150 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:42090)->kiran1-cassandra-int-seed-service/<IP_ADDRESS>:7000-URGENT_MESSAGES-fc30b92f successfully connected, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-12] 2023-06-08 07:05:52,402 InboundConnectionInitiator.java:464 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:39790)->/<IP_ADDRESS>:7000-URGENT_MESSAGES-3afba79c messaging connection established, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-11] 2023-06-08 07:05:52,402 InboundConnectionInitiator.java:464 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:52276)->/<IP_ADDRESS>:7000-URGENT_MESSAGES-7ef8a76c messaging connection established, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-10] 2023-06-08 07:05:52,402 InboundConnectionInitiator.java:464 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:36300)->/<IP_ADDRESS>:7000-URGENT_MESSAGES-5f76972e messaging connection established, version = 12, framing = LZ4, encryption = unencrypted
INFO  [main] 2023-06-08 07:05:53,325 StorageService.java:959 - Starting up server gossip
INFO  [main] 2023-06-08 07:05:53,329 ColumnFamilyStore.java:878 - Enqueuing flush of local: 0.459KiB (0%) on-heap, 0.000KiB (0%) off-heap
INFO  [PerDiskMemtableFlushWriter_0:1] 2023-06-08 07:05:53,335 Memtable.java:469 - Writing Memtable-local@1375811256(0.048KiB serialized bytes, 1 ops, 0%/0% of on/off-heap limit), flushed range = (min(-9223372036854775808), max(9223372036854775807)]
INFO  [PerDiskMemtableFlushWriter_0:1] 2023-06-08 07:05:53,335 Memtable.java:498 - Completed flushing /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-10-big-Data.db (0.028KiB) for commitlog position CommitLogPosition(segmentId=1686207949124, position=31385)
INFO  [MemtableFlushWriter:1] 2023-06-08 07:05:53,350 LogTransaction.java:240 - Unfinished transaction log, deleting /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb_txn_flush_e842f920-05ca-11ee-89ed-bd5ee214825f.log
WARN  [main] 2023-06-08 07:05:53,356 K8SeedProvider4x.java:58 - Seed provider couldn't lookup host kiran1-cassandra-int-dc1-additional-seed-service
INFO  [main] 2023-06-08 07:05:53,359 TokenMetadata.java:511 - Updating topology for /<IP_ADDRESS>:7000
INFO  [main] 2023-06-08 07:05:53,359 TokenMetadata.java:511 - Updating topology for /<IP_ADDRESS>:7000
WARN  [main] 2023-06-08 07:05:53,377 K8SeedProvider4x.java:58 - Seed provider couldn't lookup host kiran1-cassandra-int-dc1-additional-seed-service
INFO  [main] 2023-06-08 07:05:53,379 StorageService.java:1071 - Using saved tokens [-1201388703392398296, -193144681688535003, -2407626167822201472, -3797912864131843442, -4791680523270731906, -5660584635528349951, -7151614837324625709, -8789039999460179265,<PHONE_NUMBER>407202174,<PHONE_NUMBER>085982538,<PHONE_NUMBER>440152055,<PHONE_NUMBER>07222706,<PHONE_NUMBER>605401730,<PHONE_NUMBER>875920601,<PHONE_NUMBER>195033648,<PHONE_NUMBER>804169695]
INFO  [main] 2023-06-08 07:05:53,404 StorageService.java:1633 - JOINING: Finish joining ring
INFO  [main] 2023-06-08 07:05:53,409 StorageService.java:2784 - Node /<IP_ADDRESS>:7000 state jump to NORMAL
INFO  [main] 2023-06-08 07:05:53,412 StorageService.java:2784 - Node /<IP_ADDRESS>:7000 state jump to NORMAL
INFO  [main] 2023-06-08 07:05:53,413 Gossiper.java:2214 - Waiting for gossip to settle...
INFO  [ScheduledTasks:1] 2023-06-08 07:05:53,724 TokenMetadata.java:531 - Updating topology for all endpoints that have changed
INFO  [GossipStage:1] 2023-06-08 07:05:54,365 Gossiper.java:1362 - Node /<IP_ADDRESS>:7000 has restarted, now UP
INFO  [GossipStage:1] 2023-06-08 07:05:54,366 StorageService.java:2784 - Node /<IP_ADDRESS>:7000 state jump to NORMAL
INFO  [GossipStage:1] 2023-06-08 07:05:54,378 TokenMetadata.java:511 - Updating topology for /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:54,379 TokenMetadata.java:511 - Updating topology for /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:54,382 Gossiper.java:1362 - Node /<IP_ADDRESS>:7000 has restarted, now UP
INFO  [GossipStage:1] 2023-06-08 07:05:54,382 StorageService.java:2784 - Node /<IP_ADDRESS>:7000 state jump to NORMAL
INFO  [GossipStage:1] 2023-06-08 07:05:54,387 TokenMetadata.java:511 - Updating topology for /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:54,388 TokenMetadata.java:511 - Updating topology for /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:54,391 Gossiper.java:1362 - Node /<IP_ADDRESS>:7000 has restarted, now UP
INFO  [GossipStage:1] 2023-06-08 07:05:54,392 StorageService.java:2784 - Node /<IP_ADDRESS>:7000 state jump to NORMAL
INFO  [GossipStage:1] 2023-06-08 07:05:54,396 TokenMetadata.java:511 - Updating topology for /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:54,397 TokenMetadata.java:511 - Updating topology for /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:54,403 Gossiper.java:1312 - InetAddress /<IP_ADDRESS>:7000 is now UP
INFO  [GossipStage:1] 2023-06-08 07:05:54,403 Gossiper.java:1312 - InetAddress /<IP_ADDRESS>:7000 is now UP
INFO  [GossipStage:1] 2023-06-08 07:05:54,403 Gossiper.java:1312 - InetAddress /<IP_ADDRESS>:7000 is now UP
INFO  [GossipStage:1] 2023-06-08 07:05:54,404 Gossiper.java:1312 - InetAddress /<IP_ADDRESS>:7000 is now UP
INFO  [GossipStage:1] 2023-06-08 07:05:54,404 Gossiper.java:1312 - InetAddress /<IP_ADDRESS>:7000 is now UP
INFO  [GossipStage:1] 2023-06-08 07:05:54,432 Gossiper.java:1312 - InetAddress /<IP_ADDRESS>:7000 is now UP
INFO  [GossipStage:1] 2023-06-08 07:05:56,581 Gossiper.java:1364 - Node /<IP_ADDRESS>:7000 is now part of the cluster
WARN  [GossipStage:1] 2023-06-08 07:05:56,586 StorageService.java:2824 - Not updating host ID 1c137489-ed6f-4400-adb4-31435832d8d4 for /<IP_ADDRESS>:7000 because it's mine
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -1201388703392398296.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -193144681688535003.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -2407626167822201472.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -3797912864131843442.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -4791680523270731906.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -5660584635528349951.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -7151614837324625709.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -8789039999460179265.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>407202174.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>085982538.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>440152055.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>07222706.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>605401730.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>875920601.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>195033648.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,587 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>804169695.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,591 ColumnFamilyStore.java:878 - Enqueuing flush of peers: 12.971KiB (0%) on-heap, 0.000KiB (0%) off-heap
INFO  [GossipStage:1] 2023-06-08 07:05:56,592 ColumnFamilyStore.java:878 - Enqueuing flush of peers_v2: 13.193KiB (0%) on-heap, 0.000KiB (0%) off-heap
INFO  [PerDiskMemtableFlushWriter_0:2] 2023-06-08 07:05:56,599 Memtable.java:469 - Writing Memtable-peers@1352895258(2.380KiB serialized bytes, 47 ops, 0%/0% of on/off-heap limit), flushed range = (min(-9223372036854775808), max(9223372036854775807)]
INFO  [PerDiskMemtableFlushWriter_0:2] 2023-06-08 07:05:56,600 Memtable.java:498 - Completed flushing /var/lib/cassandra/data/system/peers-37f71aca7dc2383ba70672528af04d4f/nb-2-big-Data.db (1.451KiB) for commitlog position CommitLogPosition(segmentId=1686207949124, position=40452)
INFO  [PerDiskMemtableFlushWriter_0:1] 2023-06-08 07:05:56,600 Memtable.java:469 - Writing Memtable-peers_v2@964924550(2.311KiB serialized bytes, 47 ops, 0%/0% of on/off-heap limit), flushed range = (min(-9223372036854775808), max(9223372036854775807)]
INFO  [PerDiskMemtableFlushWriter_0:1] 2023-06-08 07:05:56,601 Memtable.java:498 - Completed flushing /var/lib/cassandra/data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/nb-2-big-Data.db (1.495KiB) for commitlog position CommitLogPosition(segmentId=1686207949124, position=40452)
INFO  [MemtableFlushWriter:2] 2023-06-08 07:05:56,623 LogTransaction.java:240 - Unfinished transaction log, deleting /var/lib/cassandra/data/system/peers-37f71aca7dc2383ba70672528af04d4f/nb_txn_flush_ea34b700-05ca-11ee-89ed-bd5ee214825f.log
INFO  [MemtableFlushWriter:1] 2023-06-08 07:05:56,624 LogTransaction.java:240 - Unfinished transaction log, deleting /var/lib/cassandra/data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/nb_txn_flush_ea34de10-05ca-11ee-89ed-bd5ee214825f.log
INFO  [GossipStage:1] 2023-06-08 07:05:56,626 Gossiper.java:1328 - InetAddress /<IP_ADDRESS>:7000 is now DOWN
WARN  [GossipStage:1] 2023-06-08 07:05:56,630 StorageService.java:2824 - Not updating host ID 1c137489-ed6f-4400-adb4-31435832d8d4 for /<IP_ADDRESS>:7000 because it's mine
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -1201388703392398296.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -193144681688535003.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -2407626167822201472.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -3797912864131843442.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -4791680523270731906.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -5660584635528349951.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -7151614837324625709.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token -8789039999460179265.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>407202174.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>085982538.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>440152055.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>07222706.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>605401730.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>875920601.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>195033648.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>804169695.  Ignoring /<IP_ADDRESS>:7000
INFO  [GossipStage:1] 2023-06-08 07:05:56,633 ColumnFamilyStore.java:878 - Enqueuing flush of peers: 1.140KiB (0%) on-heap, 0.000KiB (0%) off-heap
INFO  [GossipStage:1] 2023-06-08 07:05:56,633 ColumnFamilyStore.java:878 - Enqueuing flush of peers_v2: 0.663KiB (0%) on-heap, 0.000KiB (0%) off-heap
INFO  [PerDiskMemtableFlushWriter_0:2] 2023-06-08 07:05:56,639 Memtable.java:469 - Writing Memtable-peers@1419515350(0.172KiB serialized bytes, 7 ops, 0%/0% of on/off-heap limit), flushed range = (min(-9223372036854775808), max(9223372036854775807)]
INFO  [PerDiskMemtableFlushWriter_0:2] 2023-06-08 07:05:56,639 Memtable.java:498 - Completed flushing /var/lib/cassandra/data/system/peers-37f71aca7dc2383ba70672528af04d4f/nb-3-big-Data.db (0.019KiB) for commitlog position CommitLogPosition(segmentId=1686207949124, position=41458)
INFO  [PerDiskMemtableFlushWriter_0:1] 2023-06-08 07:05:56,640 Memtable.java:469 - Writing Memtable-peers_v2@1480539200(0.032KiB serialized bytes, 7 ops, 0%/0% of on/off-heap limit), flushed range = (min(-9223372036854775808), max(9223372036854775807)]
INFO  [PerDiskMemtableFlushWriter_0:1] 2023-06-08 07:05:56,640 Memtable.java:498 - Completed flushing /var/lib/cassandra/data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/nb-3-big-Data.db (0.030KiB) for commitlog position CommitLogPosition(segmentId=1686207949124, position=41458)
INFO  [MemtableFlushWriter:2] 2023-06-08 07:05:56,653 LogTransaction.java:240 - Unfinished transaction log, deleting /var/lib/cassandra/data/system/peers-37f71aca7dc2383ba70672528af04d4f/nb_txn_flush_ea3af890-05ca-11ee-89ed-bd5ee214825f.log
INFO  [MemtableFlushWriter:1] 2023-06-08 07:05:56,656 LogTransaction.java:240 - Unfinished transaction log, deleting /var/lib/cassandra/data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/nb_txn_flush_ea3b1fa0-05ca-11ee-89ed-bd5ee214825f.log
INFO  [Messaging-EventLoop-3-15] 2023-06-08 07:05:58,589 NoSpamLogger.java:92 - /<IP_ADDRESS>:7000->/<IP_ADDRESS>:7000-URGENT_MESSAGES-[no-channel] failed to connect
io.netty.channel.ConnectTimeoutException: connection timed out: /<IP_ADDRESS>:7000
at io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe$2.run(AbstractEpollChannel.java:576)
at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98)
at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:170)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
INFO  [main] 2023-06-08 07:06:01,414 Gossiper.java:2245 - No gossip backlog; proceeding
INFO  [main] 2023-06-08 07:06:01,418 AuthCache.java:215 - (Re)initializing CredentialsCache (validity period/update interval/max entries) (3600000/3600000/1000)
INFO  [main] 2023-06-08 07:06:01,428 StartupClusterConnectivityChecker.java:111 - Blocking coordination until only a single peer is DOWN in the local datacenter, timeout=10s
INFO  [Messaging-EventLoop-3-8] 2023-06-08 07:06:01,436 OutboundConnection.java:1150 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:44272)->kiran1-cassandra-int-seed-service/<IP_ADDRESS>:7000-LARGE_MESSAGES-ee77aa8b successfully connected, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-7] 2023-06-08 07:06:01,436 OutboundConnection.java:1150 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:44268)->kiran1-cassandra-int-seed-service/<IP_ADDRESS>:7000-SMALL_MESSAGES-cec8964c successfully connected, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-4] 2023-06-08 07:06:01,436 OutboundConnection.java:1150 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:45584)->kiran1-cassandra-int-seed-service/<IP_ADDRESS>:7000-SMALL_MESSAGES-57f0d6a5 successfully connected, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-2] 2023-06-08 07:06:01,436 OutboundConnection.java:1150 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:40952)->kiran1-cassandra-int-seed-service/<IP_ADDRESS>:7000-LARGE_MESSAGES-748da860 successfully connected, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-1] 2023-06-08 07:06:01,436 OutboundConnection.java:1150 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:40942)->kiran1-cassandra-int-seed-service/<IP_ADDRESS>:7000-SMALL_MESSAGES-7be8429f successfully connected, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-5] 2023-06-08 07:06:01,437 OutboundConnection.java:1150 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:45600)->kiran1-cassandra-int-seed-service/<IP_ADDRESS>:7000-LARGE_MESSAGES-8f49d233 successfully connected, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-16] 2023-06-08 07:06:01,439 InboundConnectionInitiator.java:464 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:42850)->/<IP_ADDRESS>:7000-SMALL_MESSAGES-e246d8e4 messaging connection established, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-17] 2023-06-08 07:06:01,439 InboundConnectionInitiator.java:464 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:55940)->/<IP_ADDRESS>:7000-SMALL_MESSAGES-d0ed7bb9 messaging connection established, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-18] 2023-06-08 07:06:01,440 InboundConnectionInitiator.java:464 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:35392)->/<IP_ADDRESS>:7000-SMALL_MESSAGES-ec557cc4 messaging connection established, version = 12, framing = LZ4, encryption = unencrypted
INFO  [CompactionExecutor:2] 2023-06-08 07:06:01,441 CompactionTask.java:150 - Compacting (ed178ba0-05ca-11ee-89ed-bd5ee214825f) [/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-7-big-Data.db:level=0, /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-8-big-Data.db:level=0, /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-9-big-Data.db:level=0, /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-10-big-Data.db:level=0, ]
INFO  [Messaging-EventLoop-3-19] 2023-06-08 07:06:01,442 InboundConnectionInitiator.java:464 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:42858)->/<IP_ADDRESS>:7000-LARGE_MESSAGES-75039b82 messaging connection established, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-21] 2023-06-08 07:06:01,445 InboundConnectionInitiator.java:464 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:35400)->/<IP_ADDRESS>:7000-LARGE_MESSAGES-68a51da5 messaging connection established, version = 12, framing = LZ4, encryption = unencrypted
INFO  [Messaging-EventLoop-3-20] 2023-06-08 07:06:01,445 InboundConnectionInitiator.java:464 - /<IP_ADDRESS>:7000(/<IP_ADDRESS>:55952)->/<IP_ADDRESS>:7000-LARGE_MESSAGES-a1403a5f messaging connection established, version = 12, framing = LZ4, encryption = unencrypted
INFO  [main] 2023-06-08 07:06:01,446 StartupClusterConnectivityChecker.java:166 - Ensured sufficient healthy connections with [dc1] after 15 milliseconds
INFO  [main] 2023-06-08 07:06:01,458 NativeTransportService.java:130 - Using Netty Version: [netty-buffer=netty-buffer-4.1.58.Final.10b03e6, netty-codec=netty-codec-4.1.58.Final.10b03e6, netty-codec-dns=netty-codec-dns-4.1.58.Final.10b03e6, netty-codec-haproxy=netty-codec-haproxy-4.1.58.Final.10b03e6, netty-codec-http=netty-codec-http-4.1.58.Final.10b03e6, netty-codec-http2=netty-codec-http2-4.1.58.Final.10b03e6, netty-codec-memcache=netty-codec-memcache-4.1.58.Final.10b03e6, netty-codec-mqtt=netty-codec-mqtt-4.1.58.Final.10b03e6, netty-codec-redis=netty-codec-redis-4.1.58.Final.10b03e6, netty-codec-smtp=netty-codec-smtp-4.1.58.Final.10b03e6, netty-codec-socks=netty-codec-socks-4.1.58.Final.10b03e6, netty-codec-stomp=netty-codec-stomp-4.1.58.Final.10b03e6, netty-codec-xml=netty-codec-xml-4.1.58.Final.10b03e6, netty-common=netty-common-4.1.58.Final.10b03e6, netty-handler=netty-handler-4.1.60.Final.eef26e8 (repository: dirty), netty-handler-proxy=netty-handler-proxy-4.1.58.Final.10b03e6, netty-resolver=netty-resolver-4.1.58.Final.10b03e6, netty-resolver-dns=netty-resolver-dns-4.1.58.Final.10b03e6, netty-resolver-dns-native-macos=netty-resolver-dns-native-macos-4.1.58.Final.10b03e65f1, netty-transport=netty-transport-4.1.58.Final.10b03e6, netty-transport-native-epoll=netty-transport-native-epoll-4.1.58.Final.10b03e6, netty-transport-native-kqueue=netty-transport-native-kqueue-4.1.58.Final.10b03e65f1, netty-transport-native-unix-common=netty-transport-native-unix-common-4.1.58.Final.10b03e6, netty-transport-rxtx=netty-transport-rxtx-4.1.58.Final.10b03e6, netty-transport-sctp=netty-transport-sctp-4.1.58.Final.10b03e6, netty-transport-udt=netty-transport-udt-4.1.58.Final.10b03e6]
INFO  [main] 2023-06-08 07:06:01,516 NativeTransportService.java:68 - Netty using native Epoll event loop
INFO  [CompactionExecutor:2] 2023-06-08 07:06:01,529 CompactionTask.java:241 - Compacted (ed178ba0-05ca-11ee-89ed-bd5ee214825f) 4 sstables to [/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-11-big,] to level=0.  0.974KiB to 0.671KiB (~68% of original) in 85ms.  Read Throughput = 11.397KiB/s, Write Throughput = 7.854KiB/s, Row Throughput = ~2/s.  4 total partitions merged to 1.  Partition merge counts were {4:1, }
INFO  [NonPeriodicTasks:1] 2023-06-08 07:06:01,530 SSTable.java:111 - Deleting sstable: /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-7-big
INFO  [NonPeriodicTasks:1] 2023-06-08 07:06:01,531 SSTable.java:111 - Deleting sstable: /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-8-big
INFO  [NonPeriodicTasks:1] 2023-06-08 07:06:01,532 SSTable.java:111 - Deleting sstable: /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-9-big
INFO  [NonPeriodicTasks:1] 2023-06-08 07:06:01,533 SSTable.java:111 - Deleting sstable: /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-10-big
INFO  [main] 2023-06-08 07:06:01,543 PipelineConfigurator.java:124 - Using Netty Version: [netty-buffer=netty-buffer-4.1.58.Final.10b03e6, netty-codec=netty-codec-4.1.58.Final.10b03e6, netty-codec-dns=netty-codec-dns-4.1.58.Final.10b03e6, netty-codec-haproxy=netty-codec-haproxy-4.1.58.Final.10b03e6, netty-codec-http=netty-codec-http-4.1.58.Final.10b03e6, netty-codec-http2=netty-codec-http2-4.1.58.Final.10b03e6, netty-codec-memcache=netty-codec-memcache-4.1.58.Final.10b03e6, netty-codec-mqtt=netty-codec-mqtt-4.1.58.Final.10b03e6, netty-codec-redis=netty-codec-redis-4.1.58.Final.10b03e6, netty-codec-smtp=netty-codec-smtp-4.1.58.Final.10b03e6, netty-codec-socks=netty-codec-socks-4.1.58.Final.10b03e6, netty-codec-stomp=netty-codec-stomp-4.1.58.Final.10b03e6, netty-codec-xml=netty-codec-xml-4.1.58.Final.10b03e6, netty-common=netty-common-4.1.58.Final.10b03e6, netty-handler=netty-handler-4.1.60.Final.eef26e8 (repository: dirty), netty-handler-proxy=netty-handler-proxy-4.1.58.Final.10b03e6, netty-resolver=netty-resolver-4.1.58.Final.10b03e6, netty-resolver-dns=netty-resolver-dns-4.1.58.Final.10b03e6, netty-resolver-dns-native-macos=netty-resolver-dns-native-macos-4.1.58.Final.10b03e65f1, netty-transport=netty-transport-4.1.58.Final.10b03e6, netty-transport-native-epoll=netty-transport-native-epoll-4.1.58.Final.10b03e6, netty-transport-native-kqueue=netty-transport-native-kqueue-4.1.58.Final.10b03e65f1, netty-transport-native-unix-common=netty-transport-native-unix-common-4.1.58.Final.10b03e6, netty-transport-rxtx=netty-transport-rxtx-4.1.58.Final.10b03e6, netty-transport-sctp=netty-transport-sctp-4.1.58.Final.10b03e6, netty-transport-udt=netty-transport-udt-4.1.58.Final.10b03e6]
INFO  [main] 2023-06-08 07:06:01,543 PipelineConfigurator.java:125 - Starting listening for CQL clients on /<IP_ADDRESS>:9042 (optionally encrypted)...
INFO  [main] 2023-06-08 07:06:01,556 CassandraDaemonInterceptor.java:59 - Starting DataStax Metric Collector for Apache Cassandra 0.3.0
INFO  [main] 2023-06-08 07:06:01,564 ConfigurationLoader.java:62 - Configuration location: file:/opt/metrics-collector/config/metric-collector.yaml
INFO  [main] 2023-06-08 07:06:01,635 CollectdController.java:469 - /opt/metrics-collector/config/collectd.conf.tmpl
INFO  [main] 2023-06-08 07:06:01,694 UnixSocketClient.java:381 - Connection to collectd established
INFO  [main] 2023-06-08 07:06:02,064 UnixSocketClient.java:579 - Starting metric reporting with 30 sec interval
INFO  [main] 2023-06-08 07:06:02,414 CassandraDaemonInterceptor.java:62 - Starting DataStax Management API Agent for Apache Cassandra v0.1
WARN  [main] 2023-06-08 07:06:02,476 CassandraDaemonInterceptor.java:101 - Problem starting DataStax Management API for Apache Cassandra
java.lang.NullPointerException: null
at java.base/sun.nio.fs.UnixPath.normalizeAndCheck(UnixPath.java:75)
at java.base/sun.nio.fs.UnixPath.(UnixPath.java:69)
at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
at java.base/java.nio.file.Path.of(Path.java:147)
at java.base/java.nio.file.Paths.get(Paths.java:69)
at com.datastax.mgmtapi.interceptors.CassandraDaemonInterceptor.intercept(CassandraDaemonInterceptor.java:70)
at org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java)
at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:780)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
INFO  [main] 2023-06-08 07:06:02,476 CassandraDaemon.java:782 - Startup complete
WARN  [Messaging-EventLoop-3-15] 2023-06-08 07:06:06,682 NoSpamLogger.java:95 - /<IP_ADDRESS>:7000->/<IP_ADDRESS>:7000-URGENT_MESSAGES-[no-channel] dropping message of type ECHO_REQ whose timeout expired before reaching the network
INFO  [GossipTasks:1] 2023-06-08 07:06:58,445 Gossiper.java:1057 - FatClient /<IP_ADDRESS>:7000 has been silent for 30000ms, removing from gossip
INFO  [Messaging-EventLoop-3-15] 2023-06-08 07:10:58,593 NoSpamLogger.java:92 - /<IP_ADDRESS>:7000->/<IP_ADDRESS>:7000-URGENT_MESSAGES-[no-channel] failed to connect
io.netty.channel.ConnectTimeoutException: connection timed out: /<IP_ADDRESS>:7000
at io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe$2.run(AbstractEpollChannel.java:576)
at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98)
at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:170)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:384)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)`

INFO [GossipStage:1] 2023-06-08 07:05:56,631 StorageService.java:2722 - Nodes /<IP_ADDRESS>:7000 and /<IP_ADDRESS>:7000 have the same token<PHONE_NUMBER>085982538.  Are you somehow sharing disks or something between nodes? Or how did the nodes get the same token?

We use EBS volumes and not sharing any disks with nodes. I can quickly recreate a new cluster and share the logs again

@burmanm i have created a new cluster and tested it, the result is the same when I use helm to update the size  4, however when I directly update the cassdc object then the process works as expected and within a few mins the pod 4 becomes healthy.

What's the helm command you use to update the size?

I use helm diff upgrade
helm diff upgrade kiran1-cassandra-int ./charts/k8ssandra --color --install -n kiran1-cassandra-int --values ./values/region/values.yaml --values ./values/region/env/values.yaml --values values/region/int/k8sname/values.yaml --values values/region/int/k8s/kiran1-cassandra-int/values.yaml


sqlite filer backend breaks on delete

$ weed version
version 30GB 2.59  linux **amd64
$ cat filer.toml
[sqlite]
enabled = true
dbFile = "./data-filer/filer.sqlite"

Copy some data under /foo. Mount the FUSE filesystem. Run rm -rf mountpoint/foo/bar/quux. Observe this error:
I0723 14:10:18 84299 dir.go:462] remove /foo/bar/quux: delete directory /foo/bar/quux: filer store delete: deleteFolderChildren /foo/bar/quux: SQL logic error: near "LIMIT": syntax error (1)

Thanks for reporting! This should have already been fixed in https://github.com/chrislusf/seaweedfs/commit/182288f8606bde8bfcb31509335a4c33802db254
You can use the dev version https://github.com/chrislusf/seaweedfs/releases/dev to confirm.

Thanks for reporting! This should have already been fixed in 182288f
You can use the dev version https://github.com/chrislusf/seaweedfs/releases/dev to confirm.
@chrislusf
This is a fix

tar xzf sqlite-3.6.20.tar.gz
cd sqlite-3.6.20
export CFLAGS='-DSQLITE_ENABLE_UPDATE_DELETE_LIMIT=1'
./configure
make

Or
DELETE FROM Foo
WHERE someColumn in
(
  SELECT someColumn FROM FOO WHERE SomeCondition LIMIT 200
)

Please re-open

How about adding this option for mysql and postgres?
deletion_chunk_size=0

Default to zero to avoid impacting sqlite adapter, which reuses mysql adapter code.


[BUG] Does not work with Vim enabled

Hi! I just started using vimium and was very happy to find your plugin. I have installed it and tried it using :obcommand vimium:show-markers. The link markers are shown, but nothing happens when I write the shortcut.

Is this plugin working yet, or is it early WIP?
Do I need to do anything else to get it working? I have vim mode and vimrc plugin working. Is it perhaps a conflict with with other keys? Do I need to add a leader key or something? Or do you have any other idea on what could be the reason it doesn't work?

Thanks and hope you'll keep maintaining this. Link markers was the missing piece for me.

There should be no leader key. What is :obcommand, is that when you enable Vim in Obsidian to execute commands? What platform are you on?
It could maybe be a conflict with other keys in Vim mode if it also takes the keys. I will test this in the weekend. You can also test it by disabling Vim and vimrc and reloading Obsidian.

:obcommand comes from https://github.com/esm7/obsidian-vimrc-support?tab=readme-ov-file#executing-obsidian-commands-with-obcommand and is just a way to invoke obsidian commands, sorry for that confusion.
Yes, I'll check around for potential conflicts.

Hi I was able to reproduce your problem. It is when you are inside a file and have enabled Settings > Editor > Vim. It takes the keys and Vimium can't get them. This does not happen when you are in the editor and Vim is turned off. I am not sure if its possible to take precedence over the editor and Vim setting when the Vimium: Show markers is running, but I don't think so. I can maybe look into it at some point.
I feel like you could use vimrc support to create shortcuts yourself to run commands you use often.
I have renamed the issue so other people can find it, if they maybe have any ideas on how to fix this.

Ok, good that you were able to reproduce it! I hope that you can find a way to solve it, it would be great if these vim-isch modes/tools would work well together. I won't be able to use this plugin if it requires me to inactivate vim mode!
I don't understand what you mean with "I feel like you could use vimrc support to create shortcuts yourself to run commands you use often.", of course I have done so.
I unfortunately haven't done much plugin development so I don't have much input atm.

I think we are talking past each other:) I have many custom keybindings, yes. I just didn't see how it could be used to create a workaround for the issue here, if that was what you meant.
I know how to activate the marker mode. It is what happens next that is the problem. I want to press SK or LL or whatever.

You might try disable obsidian vim mode when Vimium plugin activates and reenable immediately when vimium finishes or canceled.

I switched to using Obsidian in Neovim (with obsidian.nvim and render-markdown.nvim). I'll close this issue.


[LoadFailure] Show a pretty view when loading fails and allows retrying.

Fixes https://github.com/artsy/eigen/issues/1429

          1 Warning

:warning:
The following files do not have tests: lib/app_registry.js & lib/components/load_failure_view.js

  Generated by :no_entry_sign: danger

🔥


fix(mount): fix parent disk detection for nvme devices.

nvme devices has a different syspath since it belongs to a different subsystem. Thus the nvme instance name need to be searched instead of the block keyword. This will help identify the parent disk.
Signed-off-by: Akhil Mohan<EMAIL_ADDRESS>

Codecov Report

Merging #328 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #328      +/-   ##
==========================================
+ Coverage   52.74%   52.78%   +0.03%
==========================================
  Files          50       50
  Lines        2387     2389       +2
==========================================
+ Hits         1259     1261       +2
  Misses       1031     1031
  Partials       97       97

Impacted Files
Coverage Δ

pkg/mount/mountutil.go
84.84% <100%> (+0.47%)
:arrow_up:

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 561c100...a37d736. Read the comment docs.

@AmitKumarDas  added unit test cases.


Removal of light client from substrate

As discussed in the retreat we are simplifying before refactoring by not shipping a light client out of the box with substrate. (Current users should look towards https://github.com/paritytech/substrate-connect as a purpose built solution to this usecase)
The client network tests that support light client requests use a full light client at the moment which is why more is not initially removed.
polkadot companion: https://github.com/paritytech/polkadot/pull/4105
cumulus companion: https://github.com/paritytech/cumulus/pull/687

There's a lot of stuff that may be removed from client/db as well. Also I guess we can remove everything related to CHTs as well.

skip check-dependent-cumulus

@arkpar the problem I have removing the light client db is that the networking tests test light client rpc functionality and the 'test' light client uses the light client db at the moment.

Just have read this. The task of this pr is to remove this stuff. I mean these light client tests make sense and should stay, but then we need a refactoring or whatever. However, most/all of the crate should be removed.

@bkchr I'll remove the rest of the light client stuff along with CHTs and change tries in the follow-up PR. I think we can merge this one as it is.

bot merge


[Trent MacOS] mypy failing locally

The error
Running locally on my MacOS, on main:
(venv) trentmc@tlm-macbook: ~/code/pdr-backend $ mypy ./
pdr_backend/util/subgraph.py:30: error: "type[Web3]" has no attribute "to_hex"  [attr-defined]
pdr_backend/util/subgraph.py:36: error: "type[Web3]" has no attribute "to_text"  [attr-defined]
pdr_backend/models/base_contract.py:13: error: "Web3" has no attribute "to_checksum_address"; maybe "toChecksumAddress"?  [attr-defined]
pdr_backend/models/base_contract.py:15: error: "Web3" has no attribute "to_checksum_address"; maybe "toChecksumAddress"?  [attr-defined]
pdr_backend/models/predictoor_batcher.py:23: error: Incompatible types (expression has type "int", TypedDict item "gas" has type "Wei")  [typeddict-item]
pdr_backend/models/predictoor_contract.py:200: error: "Web3" has no attribute "from_wei"; maybe "fromWei"?  [attr-defined]
pdr_backend/models/predictoor_contract.py:201: error: "Web3" has no attribute "from_wei"; maybe "fromWei"?  [attr-defined]
pdr_backend/models/predictoor_contract.py:258: error: "Web3" has no attribute "to_wei"  [attr-defined]
Found 8 errors in 4 files (checked 119 source files)

Related data
The stable version of web3.py does have the attribute 'from_wei()`. Reference.

It used to have the attribute 'fromWei()`, but that was >1 year ago.
Same for to_hex()

In setup.py, we don't specify which version of web3.py to run.
In my computer, with venv, it went for web3 version 6.11:
(venv) trentmc@tlm-macbook: ~/code/pdr-backend $ python
Python 3.11.6 (main, Oct  2 2023, 13:45:54) [Clang 15.0.0 (clang-15<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import web3
>>> print(web3.__version__)
6.11.0

[Trent] I haven't run mypy locally since I started working on my mac.
Interestingly: remote CI mypy tests do pass.
Discussion
This could become a big problem for me when I start changing code seriously
It seems that my (Trent's) local mypy is somehow using an old version of web3.py when doing its thing.
I haven't yet been able to query mypy what version of a given package it's using. That's a good next step.
If needed, I can do mypy ignores on these complaints. But better to get to the root cause.

I just ran mypy again:
(venv) trentmc@tlm-macbook: ~/code/pdr-backend $ mypy ./
Success: no issues found in 149 source files

Nothing else to do :) :)


get_var_uses and get_var_definitions do not return expected results via HLIL functions

Version and Platform (required):

Binary Ninja Version: 3.0.3238-dev (also tried in release 3.0.3233)
OS: Windows
OS Version: 10

Bug Description:
When analyzing a MIPS big endian ELF, the  get_var_uses and get_var_definitions methods return empty lists when using HLIL, but return expected results on MLIL.
Steps To Reproduce:
Please provide all steps required to reproduce the behavior:

Open binary in UI (or headless)
Get a variable reference (type binaryninja.variable.Variable) named var
Use current_hlil.get_var_uses(var) which produces an empty list.
Try again with current_mlil and it returns a populated list of expected results.

Expected Behavior:
The return values of get_var_uses and get_var_definitions should be correct when using an HLIL function.
Screenshots:
The following works as expected when using an MLIL function:

The following does not work as expected when using an HLIL function:

Additional Information:
I can provide a mips big endian sample if you have issues reproducing.

I might be going crazy here - but this seems to work when targeting variables like $v0_19 and $s2, but fails when targeting variables like var_278 and var_300.

I've looked into this a bunch today and I don't have good answers but I do understand whats causing this to happen to some variables but not others. The issue is that we determine variable def/use via SSA form, however if a MLIL variable is Aliased no SSAVariable is created and thus there are no entries in the list allowing us to calculate the def/use. I'll be discussing this issue with the team today at our meeting, and hopefully discover how to fix this.

Fixed in build 3684


Error while compiling bitflags as a dependency

I am trying to build and compile simple code that depends on clap which in turn has bitflags as a dependency. I am getting the error
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling ansi_term v0.10.2
   Compiling bitflags v1.0.1
   Compiling winapi v0.2.8
   Compiling unicode-width v0.1.4
   Compiling strsim v0.6.0
   Compiling vec_map v0.8.0
   Compiling winapi-build v0.1.1
error: expected identifier, found keyword `in`
    --> C:\Users\evgeniy.sharapov\.cargo\registry\src\github.com-1ecc6299db9ec823\bitflags-1.0.1\src\lib.rs:1148:22
     |
1148 |                 pub (in super) fn value() -> u8 {
     |                      ^^

error: aborting due to previous error

error: Could not compile `bitflags`.
Build failed, waiting for other jobs to finish...

Am I missing something ? How could it have an error in the code ?
I am using  rustc 1.16.0 (30cf806ef 2017-03-10) and cargo-0.17.0-nightly (f9e5481 2017-03-03)

I believe bitflags 1.0 requires a Rust compiler 1.20.0 or newer. Rust Version Support

ok. It's true. I updated rust and it all works now. thank  you


Set the window title with the variable/df name when available

Seems to be impossible, not at least without a lot of kludgery.


new feature(java binding): Use std::thread::available_parallelism to replace num_cpus

Feature Description
https://github.com/apache/opendal/blob/e869a70a63c0e6ccaaeabe7678ec77ecd614f5ac/bindings/java/Cargo.toml#L160
Java binding uses num_cpus to get cpu cores. It's better to replace with std's available_parallelism.
Problem and Solution
Use std::thread::available_parallelism to replace num_cpus
Additional Context
No response
Are you willing to contribute to the development of this feature?

[ ] Yes, I am willing to contribute to the development of this feature.

If no one is working on this, I would like to give it a try.

If no one is working on this, I would like to give it a try.

Thanks, welcome to give it a try!


move to Tonel v3

Thanks @demarey, these are backward compatible with earlier Pharo versions, right?


fix: change minimum platform to 11.0

related issue
https://github.com/jpudysz/react-native-turbo-mock-location-detector/issues/10#issue-1940271916

Published: https://github.com/jpudysz/react-native-turbo-mock-location-detector/releases/tag/v2.3.1


Add some helpers to simplify cross-version/cross-platform modules

This PR attempts to minimize the boilerplate of defining cross-version cross-platform Scala modules.
Currently, cross-version cross-platform modules involves a lot annoying fiddling with overriding millSourcePath and sources and artifactName and passing around crossScalaVersion and all that.  Simple Cross/CrossScalaModules get some of the plumbing handled behind the scenes, but anything more complicated and the plumbing spills out again into plain view. And although Cross/CrossScalaModules  have less boilerplate, it's still enough boilerplate you don't want to go around defining them over and over
This PR tries to hide all of them behind helper traits CrossScalaModule.Wrapper and PlatformScalaModule, so your build file only has the logic you care about and none of the plumbing.
Major changes

We replace the artifactName definition, so that instead of reading from millModuleSegments directly, it reads from artifactNameParts: Seq[String]. This makes it easier for us to splice the artifact name parts to remove unwanted segments without needing to do fragile string manipulation

Introduce CrossScalaModule.Wrapper. This can be used when the ScalaModules you are defining are not the direct children of the Cross module, but are nested somewhere inside of it. CrossScalaModule.Wrapper shades the CrossScalaModule trait, so that any CrossScalaModule defined within its body would have the crossScalaVersion automatically wired up and the artifactNameParts properly adjusted to remove the cross segment in the middle of the artifact name

Introduce PlatformScalaModule. This is analogous to CrossScalaModule, in that it adjusts the millSourcePath/artifactNameParts to drop the last segment, and adjusts sources to include the -{jvm,js,native} suffix

Tests
The changes are largely covered by existing tests, including the example/ tests which were adjusted to make use of the new traits
Notes

We cannot make the platform-specific sub-modules into Cross modules like we do with the version-specific sub-modules, since the platform-specific submodules have pretty different types/targets defined on them and Cross modules must all be of the same type

6-cross-platform-publishing, is a lot better than before, but there is still a significant amount of boilerplate involved, especially the lines around object wrapper. Not sure if there are other things we can do to make it even easier to define these cross-version/platform modules

Haven't looked at your solution yet but, if you haven't yet, I suggest you to give a look at my plugin's code: https://github.com/lolgab/mill-crossplatform
One thing that I did was to put the Cross module in the wrapper module instead at the level of the individual platforms modules. To disable some versions from some platforms (when Scala Native didn't support Scala 3 for example) I redefined millModuleDirectChildren to filter some of them. This is a bit fragile nowadays since when we search all targets we don't use that definition.
It's a bit of a tangential feature, but it would be nice to have a dynamic def enabled: Boolean in modules that is supported and works correctly all the time, (another possible candidate is def bspEnabled to disable the IDE features for some modules and also speedup builds). Once we have that, we could also think to use the dynamic approach in Mill itself.
By the way, I will review the PR later :)

@lolgab looking at your repo, it seems your implementation has the advantage of adding a CrossPlatform for additional convenience (e.g. shared moduleDeps) whereas this PR uses a raw mill.Module. It also has the Disabling platforms dynamically ability.
I can try porting over that functionality into com-lihaoyi/mill - seems like a relatively small amount of code - and update the example accordingly

I find the Wrapper trait name hard to grasp. Maybe we can find some better name for it? And in the example we should definitely use some example domain name instead of wrapper, to make sure, the names are not bound. (They are just coincidentally named "wrapper".)

Yeah I don't like the name either, but I don't know what else to call it. Base? Root? Basically we want to do the cross-version stuff once relatively high up in the module tree, so that we don't need to repeat that stuff over and over for every module

If there's no other feedback, I'm planning on merging this tomorrow. This is a relatively spartan implementation, and somewhat different from https://github.com/lolgab/mill-crossplatform, but I think provides enough value as is. We can continue to refine the code in main if there are further improvements we would like to make

@lihaoyi Can we find a better name for the Wrapper trait?
I'm heavily time-pressured right now and your lately pushing, although very appreciated, is forcing me into reaction mode. I find it hard to come up with some better name, but Wrapper is too generic and transports exactly zero meaning about its purpose. This is API code which we need to maintain, and binary compatibility is a hard to deal with issue in Mill, even if there are some @experimental or @internal annotations. We should not rush, as changing it later is more difficult than thinking it through now.
I guess any other proposal containing the words "cross", "base" or "template" in it are already better that "wrapper".

@lefou how about CrossScalaModule.Base?

@lefou how about CrossScalaModule.Base?

That will work.

Updated the name, will probably merge tomorrow if CI is happy


Linux FS is case sensitive

:shipit:

How did this work in our CI?

My guess is that the casing was the real problem here, so since aspnetCI is windows (case insensitive) vs the failing builds on Travis/linux (case sensitive) it didn't have any trouble with the path.

Looks like this fixes the problems we were having but there's something else that was hiding under it.

I'm just going to check this in and make the other fix as it's own PR since it improves things at least.


Make it possible to read description from a file

With this pull request the --description command is augmented to read the contents of a file if the
option is a path to a readable file.

This is perfect.  Makes adding a multi-line description a cinch. 👍

can we get this merged please 👍

I needed this feature too, and since the repo this PR came from is gone, I rebased it and pushed it to https://github.com/sideshowbarker/github-release