STAT-294 ⁃ need a clear statement of account name business rule and a REGEX to scrub inputs

The naming restriction for account names is that they be

Minimum of 2 characters
Maximum of 13 characters
First 12 characters can be "a-z" or "1-5" or "."
13th character can only be "a-j" or "1-5"
Last character can't be "."
Names of length 1 character are in some instances permitted by the code but are not encouraged as a good naming practice

The regex expression used to validate these names in the faucet form is:
{code:java}
(^[a-z1-5.]{1,11}[a-z1-5]$)|(^[a-z1-5.]{12}[a-j1-5]$)
{code}
Fix is to update the regex (and the documentation on what names are allowed). The missing part of the naming rule is:

the 13th character can only be 1-5 or a-j.

This naming restriction applies to many things, including but not limited to:

accounts
named permissions
contracts

ATC
The [web form HERE|https://goo.gl/forms/OHUjugUPTu7Jv1tQ2] should accept and reject, as shown, these inputs to the 'desired account name' field.
Accept:

abc
a.b
.a
booleanjulie
tbcox123
1.3.5

Reject:

.
aa.
booleanjulien
tbcox456
tbCOX

➤ Kevin Heifner commented:

No more than 13 characters

Last character can't be '.'
13th character can only be 1-5a-j
(^[a-z1-5.]{1,11}[a-z1-5]$)|(^[a-z1-5.]{12}[a-j1-5]$)

➤ Brian Johnson commented:
You will get the same error that I believe you will get for any interface that is expecting an account_name (or any other name derived type), it will get the "name not properly normalized" exception, since the first thing that will happen is you will convert the passed in json string to an account_name.  To return the "unknown key" we would have to fabricate that exception (identify the invalid account_name and then create the same "unkown key" exception since the code's plumbing wouldn't let us pass on the non-compliant account_name.

➤ Kevin Heifner commented:
[~thomas.cox] Where is this documented? I couldn't find it.
[~brian.johnson] Does the faucet plugin handle this limitation?

➤ Kevin Heifner commented:
[~brian.johnson] I think the way it behaves is fine. My question is does this behavior cause issues with your wallet plugin seeing how you generate suggestions?

➤ Thomas B. Cox commented:
Naming of all things (accounts, permissions, etc) follow this rule. Kevin to write a blurb.

Hat tip to Jon-Eric Cook ( @joneric ) for helping chase this down.

I have a question about the regex that dictates account names, permission names, contract names.
I'm learning about it and am curious where those regex are in the code base?

➤ Brian Johnson commented:
[~kevin.heifner] It just returns the same exception listed above. [~david.atchley]'s site should be designed to anticipate other exceptions.

To accomplish the following:
first char is a-z, then 1 to 11 more chars that are a-z or 1-5, and if there's a 13th char it must be a-j or 1-5
Please see the regex below:
^[a-z][a-z1-5]{1,11}[a-j1-5]?$

➤ Brian Johnson commented:
[~thomas.cox] The Description is still missing that '.' can also be used anywhere in the name, except for the last character
So can do:
thomas.cox
But cannot do:
thomas.cox.

This allows the above to work
^[a-z][a-z1-5.]{0,10}[^.][a-j1-5]?$
https://regex101.com/r/tapOhh/4/tests

The regex below allows one to do the above
^[a-z][a-z1-5.]{0,10}([a-z1-5]|^.)[a-j1-5]?$
https://regex101.com/r/tapOhh/5/tests

➤ Kevin Heifner commented:
Type name

No more than 13 characters
Last character can't be '.'
13th character can only be 1-5a-j
(^[a-z1-5.]{1,11}[a-z1-5]$)|(^[a-z1-5.]{12}[a-j1-5]$)
account_name, permission_name, func_name are all of type name

Type type_name

string of char up to 32 chars

Types bytes

vector of char, limited only by vector platform limit

Type account_permission
struct account_permission {
    account_name                     account;
    permission_name                  permission;
};Type message

struct message {
    account_name                     code;
    func_name                        type;
    vector<account_permission>       authorization;
    bytes                            data;
};Type account_permission_weight

struct account_permission_weight {
    account_permission               permission;
    uint16                           weight;
};Type transaction

struct transaction {
    uint16                           ref_block_num;
    uint32                           ref_block_prefix;
    time                             expiration;
    vector<account_name>             scope;
    vector<account_name>             read_scope;
    vector<message>                  messages;
};Type signed_transaction

struct signed_transaction : public transaction {
    vector<signature>                signatures;
};Type key_permission_weight

struct key_permission_weight {
    public_key                       key;
    uint16                           weight;
};Type authority

struct authority {
    uint32                           threshold;
    vector<key_permission_weight>    keys;
    vector<account_permission_weight> accounts;
};ABIType type_def

struct type_def {
    type_name                        new_type_name;
    type_name                        type;
};Type action

struct action {
    name                             action_name;
    type_name                        type;
};Type table

struct table {
    name                             table_name;
    type_name                        index_type;
    vector<field_name>               key_names;
    vector<type_name>                key_types;
    type_name                        type;
};Type abi

struct abi {
    vector<type_def>                 types;
    vector<struct_t>                 structs;
    vector<action>                   actions;
    vector<table>                    tables;
};

➤ Thomas B. Cox commented:
I've saved the REGEX here for general reference:
https://regex101.com/r/d8uKrG/1

➤ Thomas B. Cox commented:
Corey can you re-enter the form and ensure it works correctly using the NEW ATC?

Acceptance Test Criteria (ATC) testing results
Rejected

.
aa.
booleanjulien
tbcox456
tbCOX

Accepted

abc
a.b
.a
booleanjulie
tbcox123
1.3.5

Note:
There is no indication of what is acceptable for the first 12 characters. Maybe the following would be an acceptable description of the naming rules.

Minimum of 2 characters
Maximum of 13 characters
First 12 characters can be "a-z" or "1-5" or "."
13th character can only be "a-j" or "1-5"
Last character can't be "."

Passed tests. Thanks to @joneric !

➤ Brian Johnson commented:
Sorry, [~thomas.cox], I don't know how I missed this, maybe it was the multiple attempts, but this is the regex:
(^[a-z1-5.]{0,11}[a-z1-5]$)|(^[a-z1-5.]{12}[a-j1-5]$)[~kevin.heifner] please double check me.
So the ATC could also accept "a" and "1".

➤ Kevin Heifner commented:
[~brian.johnson] Your regex is correct.

@blockone-syncclient I think, this regex is uncorrect, because It is inpossible create account, starting from .


 IMHO we should try to be graceful about this and give the user a meaningful error
Reproduce
apiVersion: v1
kind: Secret
metadata:
  name: cos-credentials
stringData:
  AccessKeyID: SOME-VALUE-HERE
  SecretAccessKey: SOME-OTHER-VALUE-HERE
---
apiVersion: risingwave.risingwavelabs.com/v1alpha1
kind: RisingWave
metadata:
  name: risingwave-s3-compatible
spec:
  storages:
    meta:
      memory: true
    object:
      s3:
        secret: cos-credentials
        region: eu-central-1
        bucket: somebucket
        endpoint: somebucket.${REGION}.amazonaws.com  # Incorrect endpoint
        virtualHostedStyle: true
  global:
    image: ghcr.io/risingwavelabs/risingwave:nightly-20221107
    imagePullPolicy: IfNotPresent
    resources:
      limits:
        cpu: 1
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 100Mi
    replicas:
      meta: 1
      frontend: 1
      compute: 1
      compactor: 1

Output
risingwave-s3-compatible-compactor-6fb6c6db69-vztdd   0/1     CrashLoopBackOff   7 (29s ago)     8m4s
risingwave-s3-compatible-compute-0                    0/1     CrashLoopBackOff   6 (2m44s ago)   8m4s
risingwave-s3-compatible-frontend-8558f5c54f-2vp5m    1/1     Running            0               8m4s
risingwave-s3-compatible-meta-55d979986d-dch5r        1/1     Running            0               8m4s

logs from risingwave-s3-compatible-compute-0
 k logs risingwave-s3-compatible-compute-0
launching compute node
2022-11-08T14:19:12.162902Z  INFO risingwave_rt: setting tokio worker threads to 1
2022-11-08T14:19:12.163039Z  INFO risingwave_compute: Compute node options: ComputeNodeOpts { host: "<IP_ADDRESS>:5688", client_address: Some("risingwave-s3-compatible-compute-0.risingwave-s3-compatible-compute:5688"), state_store: "hummock+s3-compatible://hummock001test", prometheus_listener_addr: "<IP_ADDRESS>:1222", metrics_level: 1, meta_address: "http://risingwave-s3-compatible-meta:5690", config_path: "/risingwave/config/risingwave.toml", enable_jaeger_tracing: false, async_stack_trace: Off, file_cache_dir: "", enable_managed_cache: false }
2022-11-08T14:19:12.163084Z  INFO risingwave_compute: Server Listening at <IP_ADDRESS>:5688
2022-11-08T14:19:12.163150Z  INFO risingwave_compute: Client address is risingwave-s3-compatible-compute-0.risingwave-s3-compatible-compute:5688
2022-11-08T14:19:12.163390Z  INFO risingwave_compute::server: Starting compute node with config ComputeNodeConfig { server: ServerConfig { heartbeat_interval_ms: 1000, connection_pool_size: 16 }, batch: BatchConfig { worker_threads_num: None, developer: DeveloperConfig { batch_output_channel_size: 64, batch_chunk_size: 1024, stream_enable_executor_row_count: false, stream_connector_message_buffer_size: 16, unsafe_stream_hash_agg_cache_size: 65536, unsafe_stream_join_cache_size: 65536, unsafe_stream_extreme_cache_size: 1024, stream_chunk_size: 1024 } }, streaming: StreamingConfig { barrier_interval_ms: 250, in_flight_barrier_nums: 40, checkpoint_frequency: 10, minimal_scheduling: false, worker_node_parallelism: 1, actor_runtime_worker_threads_num: None, total_memory_available_bytes:<PHONE_NUMBER>, developer: DeveloperConfig { batch_output_channel_size: 64, batch_chunk_size: 1024, stream_enable_executor_row_count: false, stream_connector_message_buffer_size: 16, unsafe_stream_hash_agg_cache_size: 65536, unsafe_stream_join_cache_size: 65536, unsafe_stream_extreme_cache_size: 1024, stream_chunk_size: 1024 } }, storage: StorageConfig { sstable_size_mb: 256, block_size_kb: 1024, bloom_false_positive: 0.01, share_buffers_sync_parallelism: 1, share_buffer_compaction_worker_threads_number: 4, shared_buffer_capacity_mb: 1024, data_directory: "hummock_001", write_conflict_detection_enabled: false, block_cache_capacity_mb: 256, meta_cache_capacity_mb: 64, disable_remote_compactor: false, enable_local_spill: true, local_object_store: "tempdisk", share_buffer_upload_concurrency: 8, compactor_memory_limit_mb: 512, sstable_id_remote_fetch_number: 10, file_cache: FileCacheConfig { capacity_mb: 1024, total_buffer_capacity_mb: 128, cache_file_fallocate_unit_mb: 512, cache_meta_fallocate_unit_mb: 16, cache_file_max_write_size_mb: 4 }, min_sst_size_for_streaming_upload: 33554432, max_sub_compaction: 4, object_store_use_batch_delete: true, enable_state_store_v1: false } } with debug assertions off
2022-11-08T14:19:12.166027Z  INFO risingwave_compute::server: Assigned worker node id 3
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: io error: error trying to connect: dns error: failed to lookup address information: Name or service not known
  backtrace of `ObjectError`:
   0: std::backtrace_rs::backtrace::libunwind::trace
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   1: std::backtrace_rs::backtrace::trace_unsynchronized
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2: std::backtrace::Backtrace::create
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/backtrace.rs:333:13
   3: <risingwave_object_store::object::error::ObjectError as core::convert::From<risingwave_object_store::object::error::ObjectErrorInner>>::from
             at ./risingwave/src/object_store/src/object/error.rs:38:10
   4: <T as core::convert::Into<U>>::into
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/convert/mod.rs:726:9
   5: <risingwave_object_store::object::error::ObjectError as core::convert::From<aws_smithy_http::result::SdkError<E>>>::from
             at ./risingwave/src/object_store/src/object/error.rs:81:9
   6: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/result.rs:2108:27
   7: risingwave_object_store::object::s3::S3ObjectStore::configure_bucket_lifecycle::{{closure}}
             at ./risingwave/src/object_store/src/object/s3.rs:701:13
   8: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/mod.rs:91:19
   9: risingwave_object_store::object::s3::S3ObjectStore::new_s3_compatible::{{closure}}
             at ./risingwave/src/object_store/src/object/s3.rs:572:13
  10: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/mod.rs:91:19
  11: risingwave_object_store::object::parse_remote_object_store::{{closure}}
             at ./risingwave/src/object_store/src/object/mod.rs:815:17
  12: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/mod.rs:91:19
  13: risingwave_storage::store_impl::StateStoreImpl::new::{{closure}}
             at ./risingwave/src/storage/src/store_impl.rs:152:17
  14: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/mod.rs:91:19
  15: risingwave_compute::server::compute_node_serve::{{closure}}
             at ./risingwave/src/compute/src/server.rs:118:5
  16: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/mod.rs:91:19
  17: risingwave_compute::start::{{closure}}
             at ./risingwave/src/compute/src/lib.rs:116:69
  18: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/mod.rs:91:19
  19: <core::pin::Pin<P> as core::future::future::Future>::poll
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/future.rs:124:9
  20: <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll
             at ./root/.cargo/registry/src/github.com-1ecc6299db9ec823/tracing-0.1.36/src/instrument.rs:272:9
  21: tokio::park::thread::CachedParkThread::block_on::{{closure}}
             at ./root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/park/thread.rs:267:54
  22: tokio::coop::with_budget::{{closure}}
             at ./root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/coop.rs:102:9
  23: std::thread::local::LocalKey<T>::try_with
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/thread/local.rs:446:16
  24: std::thread::local::LocalKey<T>::with
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/thread/local.rs:422:9
  25: tokio::coop::with_budget
             at ./root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/park/thread.rs:267:31
  26: tokio::coop::budget
             at ./root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/coop.rs:72:5
  27: tokio::park::thread::CachedParkThread::block_on
             at ./root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/park/thread.rs:267:31
  28: tokio::runtime::enter::Enter::block_on
             at ./root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/runtime/enter.rs:152:13
  29: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
             at ./root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/runtime/scheduler/multi_thread/mod.rs:79:9
  30: tokio::runtime::Runtime::block_on
             at ./root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/runtime/mod.rs:492:44
  31: risingwave_rt::main_okk
             at ./risingwave/src/utils/runtime/src/lib.rs:264:5
  32: risingwave::main::{{closure}}
             at ./risingwave/src/cmd_all/src/bin/risingwave.rs:50:17
  33: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/alloc/src/boxed.rs:1952:9
  34: risingwave::main
             at ./risingwave/src/cmd_all/src/bin/risingwave.rs:163:13
  35: core::ops::function::FnOnce::call_once
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/ops/function.rs:251:5
  36: std::sys_common::backtrace::__rust_begin_short_backtrace
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/sys_common/backtrace.rs:122:18
  37: std::rt::lang_start::{{closure}}
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/rt.rs:166:18
  38: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/ops/function.rs:286:13
  39: std::panicking::try::do_call
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:483:40
  40: std::panicking::try
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:447:19
  41: std::panic::catch_unwind
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panic.rs:137:14
  42: std::rt::lang_start_internal::{{closure}}
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/rt.rs:148:48
  43: std::panicking::try::do_call
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:483:40
  44: std::panicking::try
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:447:19
  45: std::panic::catch_unwind
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panic.rs:137:14
  46: std::rt::lang_start_internal
             at ./rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/rt.rs:148:20
  47: main
  48: <unknown>
  49: __libc_start_main
  50: _start
', /risingwave/src/object_store/src/object/s3.rs:573:14
stack backtrace:
   0:     0xaaaae9443de0 - std::backtrace_rs::backtrace::libunwind::trace::h04a18e7ccbcb06b1
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   1:     0xaaaae9443de0 - std::backtrace_rs::backtrace::trace_unsynchronized::he3023a106d1e983b
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0xaaaae9443de0 - std::sys_common::backtrace::_print_fmt::heef32bbe596930aa
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/sys_common/backtrace.rs:66:5
   3:     0xaaaae9443de0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h188116f30beafc25
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/sys_common/backtrace.rs:45:22
   4:     0xaaaae946d77c - core::fmt::write::h5882608e3fe006e9
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/fmt/mod.rs:1209:17
   5:     0xaaaae943c6d8 - std::io::Write::write_fmt::hf5f129ed0af94b2d
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/io/mod.rs:1682:15
   6:     0xaaaae94453f0 - std::sys_common::backtrace::_print::h5b7f4c819c680459
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/sys_common/backtrace.rs:48:5
   7:     0xaaaae94453f0 - std::sys_common::backtrace::print::h52ba7378eac337d4
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/sys_common/backtrace.rs:35:9
   8:     0xaaaae94453f0 - std::panicking::default_hook::{{closure}}::h6e4f5e51d086175e
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:267:22
   9:     0xaaaae94450e8 - std::panicking::default_hook::h921f654ba63386e3
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:286:9
  10:     0xaaaae5dd8910 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h3244ff998172224a
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/alloc/src/boxed.rs:1952:9
  11:     0xaaaae5dd8910 - risingwave_rt::set_panic_hook::{{closure}}::h5440d81392049248
                               at /risingwave/src/utils/runtime/src/lib.rs:81:9
  12:     0xaaaae5dd8910 - std::panicking::update_hook::{{closure}}::h4122e5117ab475a5
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:232:47
  13:     0xaaaae9445c20 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h931855a755dd854d
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/alloc/src/boxed.rs:1952:9
  14:     0xaaaae9445c20 - std::panicking::rust_panic_with_hook::ha40c5feea6f8040a
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:692:13
  15:     0xaaaae94459dc - std::panicking::begin_panic_handler::{{closure}}::hc4856f3b1de015c8
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:579:13
  16:     0xaaaae9444270 - std::sys_common::backtrace::__rust_end_short_backtrace::hceabb7b4314cd733
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/sys_common/backtrace.rs:138:18
  17:     0xaaaae9445720 - rust_begin_unwind
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:575:5
  18:     0xaaaae946af30 - core::panicking::panic_fmt::hab281a5433b6cc39
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/panicking.rs:65:14
  19:     0xaaaae946b2bc - core::result::unwrap_failed::h8fb7a5daf92b5ab3
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/result.rs:1791:5
  20:     0xaaaae6856cd4 - core::result::Result<T,E>::unwrap::h3ef19e5cfac6c233
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/result.rs:1113:23
  21:     0xaaaae6856cd4 - risingwave_object_store::object::s3::S3ObjectStore::new_s3_compatible::{{closure}}::h259176a6cf9b2dc1
                               at /risingwave/src/object_store/src/object/s3.rs:571:9
  22:     0xaaaae6856cd4 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h7630ca0368cdc33d
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/mod.rs:91:19
  23:     0xaaaae6856cd4 - risingwave_object_store::object::parse_remote_object_store::{{closure}}::h9f51c38f3c13c856
                               at /risingwave/src/object_store/src/object/mod.rs:815:17
  24:     0xaaaae6856cd4 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h9e57b7bbae11bc2e
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/mod.rs:91:19
  25:     0xaaaae6856cd4 - risingwave_storage::store_impl::StateStoreImpl::new::{{closure}}::ha5d2cde567dff398
                               at /risingwave/src/storage/src/store_impl.rs:152:17
  26:     0xaaaae68de9d8 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h6826ba93c6581cc9
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/mod.rs:91:19
  27:     0xaaaae68de9d8 - risingwave_compute::server::compute_node_serve::{{closure}}::h83e04e0d4181aecb
                               at /risingwave/src/compute/src/server.rs:118:5
  28:     0xaaaae68ac3cc - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h473ff048fd219e3c
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/mod.rs:91:19
  29:     0xaaaae68ac3cc - risingwave_compute::start::{{closure}}::h3f4f28b1acd7789c
                               at /risingwave/src/compute/src/lib.rs:116:69
  30:     0xaaaae68ac3cc - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h2654e9b5d3c79f44
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/mod.rs:91:19
  31:     0xaaaae5b036d0 - <core::pin::Pin<P> as core::future::future::Future>::poll::h38ffa97c1ed3d0a3
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/future/future.rs:124:9
  32:     0xaaaae5b036d0 - <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll::h9d5ccbbf351b1d46
                               at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tracing-0.1.36/src/instrument.rs:272:9
  33:     0xaaaae5b036d0 - tokio::park::thread::CachedParkThread::block_on::{{closure}}::hbc54adc2e03e3e0a
                               at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/park/thread.rs:267:54
  34:     0xaaaae5b036d0 - tokio::coop::with_budget::{{closure}}::h329aa459a32fb5cf
                               at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/coop.rs:102:9
  35:     0xaaaae5b036d0 - std::thread::local::LocalKey<T>::try_with::hfe5e8a113fce0ce7
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/thread/local.rs:446:16
  36:     0xaaaae5b036d0 - std::thread::local::LocalKey<T>::with::h581feed27a449fbd
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/thread/local.rs:422:9
  37:     0xaaaae5abe664 - tokio::coop::with_budget::hca7d6d16d406e847
                               at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/park/thread.rs:267:31
  38:     0xaaaae5abe664 - tokio::coop::budget::hbcffd4cf2b1f04a8
                               at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/coop.rs:72:5
  39:     0xaaaae5abe664 - tokio::park::thread::CachedParkThread::block_on::h9e678d4a194eb4b1
                               at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/park/thread.rs:267:31
  40:     0xaaaae5cc1a28 - tokio::runtime::enter::Enter::block_on::h3c9fbf9e60c4dad0
                               at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/runtime/enter.rs:152:13
  41:     0xaaaae5cc1a28 - tokio::runtime::scheduler::multi_thread::MultiThread::block_on::hc840d80997296e77
                               at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/runtime/scheduler/multi_thread/mod.rs:79:9
  42:     0xaaaae5c03ff4 - tokio::runtime::Runtime::block_on::h2f6230e65bedabf3
                               at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.1/src/runtime/mod.rs:492:44
  43:     0xaaaae5c60420 - risingwave_rt::main_okk::h38d642d91f68cb7f
                               at /risingwave/src/utils/runtime/src/lib.rs:264:5
  44:     0xaaaae5d29cb0 - risingwave::main::{{closure}}::h3af9da7f6a6ce4be
                               at /risingwave/src/cmd_all/src/bin/risingwave.rs:50:17
  45:     0xaaaae5d298c0 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::hb5de24c8dc08bc80
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/alloc/src/boxed.rs:1952:9
  46:     0xaaaae5d298c0 - risingwave::main::h5e9a1cd14354fb12
                               at /risingwave/src/cmd_all/src/bin/risingwave.rs:163:13
  47:     0xaaaae5a9759c - core::ops::function::FnOnce::call_once::h221cc6e932ed01d4
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/ops/function.rs:251:5
  48:     0xaaaae5a9759c - std::sys_common::backtrace::__rust_begin_short_backtrace::hf9b2cb7cc0a6c243
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/sys_common/backtrace.rs:122:18
  49:     0xaaaae5b6fae8 - std::rt::lang_start::{{closure}}::h8f8c9fcd958b2d02
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/rt.rs:166:18
  50:     0xaaaae94347bc - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h2595f7476fadd250
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/core/src/ops/function.rs:286:13
  51:     0xaaaae94347bc - std::panicking::try::do_call::ha6ea34184de7bcc3
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:483:40
  52:     0xaaaae94347bc - std::panicking::try::h678699e0d7da6047
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:447:19
  53:     0xaaaae94347bc - std::panic::catch_unwind::h2c028ce780041345
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panic.rs:137:14
  54:     0xaaaae94347bc - std::rt::lang_start_internal::{{closure}}::h1b79246b935419bb
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/rt.rs:148:48
  55:     0xaaaae94347bc - std::panicking::try::do_call::hafc072d0fb06af36
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:483:40
  56:     0xaaaae94347bc - std::panicking::try::hba7529a38a9b722a
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panicking.rs:447:19
  57:     0xaaaae94347bc - std::panic::catch_unwind::h829b46919a3bf31e
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/panic.rs:137:14
  58:     0xaaaae94347bc - std::rt::lang_start_internal::hf57a3cc7ad699fc4
                               at /rustc/b8c35ca26b191bb9a9ac669a4b3f4d3d52d97fb1/library/std/src/rt.rs:148:20
  59:     0xaaaae5d2a264 - main
  60:     0xffffb15d73fc - <unknown>
  61:     0xffffb15d74cc - __libc_start_main
  62:     0xaaaae5a69030 - _start
  63:                0x0 - <unknown>

Good point! I'm thinking about how to provide more meaningful information. The compute node crashed because it failed to connect to the object storage. It's quite reasonable. IMHO, if we want to know that some of the S3 info isn't correct, we have to have some probes run periodically outside the risingwave kernel. A good way is to have a prober running inside the operator process and let it emit events about the issue it finds. Then we can see the event by running kubectl describe. What do you think? @CAJan93

Thinks like a really good idea. A probe should definitely work. Maybe we should also add some logs to the component to tell users exactly why it is crashing. Something like:
2022-11-08T14:19:12.166027Z  FATAL risingwave_compute::server: Unable to connect against bucket 'SOME-BUCKET'. Shutting down.

Maybe we should also add some logs to the component to tell users exactly why it is crashing.

We can submit an issue on the kernel side 😄 .


Update best_practices.md

Add the Jane Street style guide to the Best Practices page.

Merged.
This is the kind of small change you can easily make without a PR as a contributor (see the contribution guidelines). Would you like to be added?


ert has two failures out-of-box on OS X, GNU Emacs <IP_ADDRESS>

To reproduce: Grab Emacs.app from http://emacsformacosx.com/
% /Applications/Emacs.app/Contents/MacOS/Emacs -batch -l rust-mode.el -l rust-mode-tests.el -f ert-run-tests-batch-and-exit
Warning: arch-dependent data dir `/Users/build/workspace/Emacs-Multi-Build/label/mavericks/emacs-source/nextstep/Emacs.app/Contents/MacOS/libexec/': No such file or directory
Running 63 tests (2015-02-06 00:47:59+0100)
Test auto-fill-multi-line-doc-comment backtrace:
  (if (unwind-protect (setq value-72102 (apply fn-72100 args-72101)) (
  (let (form-description-72104) (if (unwind-protect (setq value-72102
  (let ((value-72102 (quote ert-form-evaluation-aborted-72103))) (let
  (let ((fn-72100 (function rust-compare-code-after-manip)) (args-7210
  (progn (rust-mode) (insert original) (goto-char point-pos) (funcall
  (unwind-protect (progn (rust-mode) (insert original) (goto-char poin
  (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
  (let ((temp-buffer (generate-new-buffer " *temp*"))) (save-current-b
  rust-test-manip-code("/**\n *\n */" 8 (lambda nil (unwind-protect (p
  test-auto-fill("/**\n *\n */" 8 "This is a very very very very very
  (lambda nil (test-auto-fill "/**\n *\n */" 8 "This is a very very ve
  #[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\317\320%DC
  funcall(#[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\31
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  #[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\316%DC\2
  funcall(#[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\
  ert-run-test([cl-struct-ert-test auto-fill-multi-line-doc-comment ni
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test a
  ert-run-tests(t #[385 "\306\307\"\203D\211\211G\310U\203\211@\20
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  command-line-1(("-l" "rust-mode.el" "-l" "rust-mode-tests.el" "-f" "
  command-line()
  normal-top-level()
Test auto-fill-multi-line-doc-comment condition:
    (ert-test-failed
     ((should
       (rust-compare-code-after-manip original point-pos manip-func expected
				      (buffer-string)))
      :form
      (rust-compare-code-after-manip "/**\n *\n */" 8
				     (lambda nil
				       (unwind-protect ... ...))
				     "/**\n * This is a very very very very\n * very very very long string\n */" "/**\n *\nThis is a very very very very\nvery very very long string */")
      :value nil :explanation
      ("Rust code was manipulated wrong after:"
       (insert "/**\n *\n */")
       (goto-char 8)
       expected
       (insert "/**\n * This is a very very very very\n * very very very long string\n */")
       got
       (insert "/**\n *\nThis is a very very very very\nvery very very long string */")
       (first-difference-at
	(goto-char 7)
	expected " " got "\n"))))
   FAILED   1/63  auto-fill-multi-line-doc-comment
   passed   2/63  auto-fill-multi-line-prefixless
   passed   3/63  auto-fill-single-line-doc-comment
   passed   4/63  fill-paragraph-multi-line-style-inner-doc-comment
   passed   5/63  fill-paragraph-multi-paragraph-multi-line-style-doc-comment
   passed   6/63  fill-paragraph-multi-paragraph-single-line-style-doc-comment
   passed   7/63  fill-paragraph-multi-paragraph-single-line-style-indented
   passed   8/63  fill-paragraph-prefixless-multi-line-doc-comment
   passed   9/63  fill-paragraph-single-line-style-code-before-and-after
   passed  10/63  fill-paragraph-single-line-style-inner-doc-comment
   passed  11/63  fill-paragraph-single-line-style-with-code-after
   passed  12/63  fill-paragraph-single-line-style-with-code-before
   passed  13/63  fill-paragraph-top-level-multi-line-style-doc-comment-first-line
   passed  14/63  fill-paragraph-top-level-multi-line-style-doc-comment-second-line
   passed  15/63  fill-paragraph-with-no-space-after-star-prefix
   passed  16/63  font-lock-attribute-around-comment
   passed  17/63  font-lock-attribute-inner
   passed  18/63  font-lock-attribute-inside-comment
   passed  19/63  font-lock-attribute-inside-string
   passed  20/63  font-lock-attribute-key-value
   passed  21/63  font-lock-attribute-simple
Indenting region...
Indenting region...done
   passed  22/63  indent-curly-braces-within-parens
Indenting region...
Indenting region...done
Test indent-doc-comments backtrace:
  (if (unwind-protect (setq value-72102 (apply fn-72100 args-72101)) (
  (let (form-description-72104) (if (unwind-protect (setq value-72102
  (let ((value-72102 (quote ert-form-evaluation-aborted-72103))) (let
  (let ((fn-72100 (function rust-compare-code-after-manip)) (args-7210
  (progn (rust-mode) (insert original) (goto-char point-pos) (funcall
  (unwind-protect (progn (rust-mode) (insert original) (goto-char poin
  (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
  (let ((temp-buffer (generate-new-buffer " *temp*"))) (save-current-b
  rust-test-manip-code("      \n      /**\n      * This is a doc comme
  (let ((deindented (replace-regexp-in-string "^[[:blank:]]*" "      "
  test-indent("\n/**\n * This is a doc comment\n *\n */\n\n/// So is t
  (lambda nil (test-indent "\n/**\n * This is a doc comment\n *\n */\n
  #[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\317\320%DC
  funcall(#[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\31
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  #[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\316%DC\2
  funcall(#[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\
  ert-run-test([cl-struct-ert-test indent-doc-comments nil (lambda nil
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test a
  ert-run-tests(t #[385 "\306\307\"\203D\211\211G\310U\203\211@\20
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  command-line-1(("-l" "rust-mode.el" "-l" "rust-mode-tests.el" "-f" "
  command-line()
  normal-top-level()
Test indent-doc-comments condition:
    (ert-test-failed
     ((should
       (rust-compare-code-after-manip original point-pos manip-func expected
				      (buffer-string)))
      :form
      (rust-compare-code-after-manip "      \n      /**\n      * This is a doc comment\n      *\n      */\n      \n      /// So is this\n      \n      fn foo() {\n      /*!\n      * this is a nested doc comment\n      */\n      \n      //! And so is this\n      }" 1
				     (lambda nil
				       (indent-region 1 ...))
				     "\n/**\n * This is a doc comment\n *\n */\n\n/// So is this\n\nfn foo() {\n    /*!\n     * this is a nested doc comment\n     */\n\n    //! And so is this\n}" "\n/**\n * This is a doc comment\n *\n */\n\n/// So is this\n\nfn foo() {\n    /*!\n     * this is a nested doc comment\n     */\n    \n    //! And so is this\n}")
      :value nil :explanation
      ("Rust code was manipulated wrong after:"
       (insert "      \n      /**\n      * This is a doc comment\n      *\n      */\n      \n      /// So is this\n      \n      fn foo() {\n      /*!\n      * this is a nested doc comment\n      */\n      \n      //! And so is this\n      }")
       (goto-char 1)
       expected
       (insert "\n/**\n * This is a doc comment\n *\n */\n\n/// So is this\n\nfn foo() {\n    /*!\n     * this is a nested doc comment\n     */\n\n    //! And so is this\n}")
       got
       (insert "\n/**\n * This is a doc comment\n *\n */\n\n/// So is this\n\nfn foo() {\n    /*!\n     * this is a nested doc comment\n     */\n    \n    //!
Indenting region...done
   passed  24/63  indent-indented-match
Indenting region...
Indenting region...done
   passed  25/63  indent-inside-braces
Mark set
Mark set
   passed  26/63  indent-line-after-whitespace-motion
Mark set
Mark set
   passed  27/63  indent-line-blank-line-indented-already-bol
Mark set
Mark set
   passed  28/63  indent-line-blank-line-indented-already-middle
Mark set
Mark set
   passed  29/63  indent-line-blank-line-motion
Mark set
Mark set
   passed  30/63  indent-line-closing-brace-motion
Mark set
Mark set
   passed  31/63  indent-line-middle-pull-motion
Mark set
Mark set
   passed  32/63  indent-line-middle-push-motion
Mark set
Mark set
   passed  33/63  indent-line-nonblank-line-indented-already-bol
Mark set
Mark set
   passed  34/63  indent-line-nonblank-line-indented-already-middle
Indenting region...
Indenting region...done
   passed  35/63  indent-match
Indenting region...
Indenting region...done
   passed  36/63  indent-match-multiline-pattern
Indenting region...
Indenting region...done
   passed  37/63  indent-multi-line-attrib
Indenting region...
Indenting region...done
   passed  38/63  indent-multi-line-expr
Indenting region...
Indenting region...done
   passed  39/63  indent-nested-fns
Indenting region...
Indenting region...done
   passed  40/63  indent-nonmatch-or-expression
Indenting region...
Indenting region...done
   passed  41/63  indent-params-align
Indenting region...
Indenting region...done
   passed  42/63  indent-params-no-align
Indenting region...
Indenting region...done
   passed  43/63  indent-square-bracket-alignment
Indenting region...
Indenting region...done
   passed  44/63  indent-struct-fields-aligned
Indenting region...
Indenting region...done
   passed  45/63  indent-top-level
   passed  46/63  indent-weirdly-indented-block
Mark set
Mark set
   passed  47/63  rust-beginning-of-defun-before-open-brace
Mark set
Mark set
   passed  48/63  rust-beginning-of-defun-between-fns
Mark set
Mark set
   passed  49/63  rust-beginning-of-defun-from-end
Mark set
Mark set
   passed  50/63  rust-beginning-of-defun-from-middle-of-fn
Mark set
Mark set
   passed  51/63  rust-beginning-of-defun-pub-fn
Mark set
Mark set
   passed  52/63  rust-beginning-of-defun-with-arg
Mark set
Mark set
   passed  53/63  rust-beginning-of-defun-with-negative-arg
Mark set
Mark set
   passed  54/63  rust-end-of-defun-before-open-brace
Mark set
Mark set
   passed  55/63  rust-end-of-defun-between-fns
Mark set
Mark set
   passed  56/63  rust-end-of-defun-from-beg
Mark set
Mark set
   passed  57/63  rust-end-of-defun-from-middle-of-fn
Mark set
Mark set
   passed  58/63  rust-end-of-defun-with-arg
Mark set
Mark set
   passed  59/63  rust-end-of-defun-with-negative-arg
Mark set
Mark set
Mark set
Mark set
Mark set
   passed  60/63  rust-mark-defun-from-end
Mark set
Mark set
Mark set
Mark set
Mark set
   passed  61/63  rust-mark-defun-from-middle-of-fn
Mark set
Mark set
Mark set
Mark set
Mark set
   passed  62/63  rust-mark-defun-from-middle-of-struct
Mark set
Mark set
Mark set
Mark set
Mark set
   passed  63/63  rust-mark-defun-start-of-defun

Ran 63 tests, 61 results as expected, 2 unexpected (2015-02-06 00:48:01+0100)

2 unexpected results:
   FAILED  auto-fill-multi-line-doc-comment
   FAILED  indent-doc-comments

(I don't know if this is Mac-specific or Emacs-version specific or what.  I will hopefully check against a Linux VM in the near future.)

ah, @MicahChalmer it appears you already have a fix for this in your repo; do you mind if I put it in?

@MicahChalmer ah in fact it seems like that commit is already a part of the other PR you wanted me to review; I will just land it separately now.

Please do...in fact the same commit is part of two different PRs I have open (since I didn't want to submit either of them with the tests still failing.)  Now at least that one won't be redundantly included in both.


[Bug] dataZoom detail shape is not the same as data with value axis

Version
5.2.2
Link to Minimal Reproduction
https://echarts.apache.org/examples/zh/editor.html?c=line-simple&code=PYBwLglsB2AEC8sDeAoWsAeBBDEDOAXMmurGAJ4gCmRA5AG4CGANgK5W0kC-ANCeTnxFUpMpRqwGLdp3S8SeKgCcIVQrADaJdCNGwAJozCMiWvaQ0BGAEw9YAZgC6fc-isBWO-4AMz7Xo1rbzt7XxdXK29g2B9Hf3Q_cwpqOmYIaA5_LhJEgyNGAC1gYABbYX88YyUwADVpCSDuFC4AbiA
Steps to Reproduce
option = {
  xAxis: {
    type: 'value'
  },
  yAxis: {
    type: 'value'
  },
  series: [
    {
      data: [
        [12, 3],
        [15, 50],
        [20, 30],
        [100, 50]
      ],
      type: 'line'
    }
  ],
  dataZoom: {
    startValue: 20
  }
};

Current Behavior
The detail view in the dataZoom is not the same as the data in range. You can see that the max value is still in the detail view of the dataZoom (wrong) but not in the chart visible area (correct).
Expected Behavior
The detail view should be the same as the chart area.
Environment
- OS:
- Browser:
- Framework:

Any additional comments?
Similar problems exists when data is not in the ascending order in xAxis (e.g., [100, 10], [50, 20]).

It seems that the detail view of dataZoom is evenly divided by 4, which is the number of series.data.length.

I'm fixing this. :) @tyn1998

I'm fixing this. :)
@Ovilia, does this issue partially overlap my old issue 17122?

Any updates on this? I'm facing the same issue


failed to build in jenkins when using specific pr title

Expected Behavior
Build gradle project on jenkins successfully.
Context
notifying a Jenkins job when a new pr is opened in github using a webhook (ghprb) -> Jenkins ghprb plugin retrieves the pr info sent >> trigger a build.
Steps to Reproduce (for bugs)
bin/gradle -DghprbActualCommitAuthorEmail=x@y -DghprbTriggerAuthorLogin= -DghprbGhRepository=project -DghprbTargetBranch=branch -DghprbPullId=1 -DghprbCredentialsId=xyz -DghprbAuthorRepoGitUrl=https://github.com -DghprbTriggerAuthor= -DghprbPullAuthorEmail= -DghprbPullLink=https://github.com/pull/1 -Dsha1=repo/pr/1/merge -DghprbPullAuthorLoginMention= "-DghprbPullDescription=GitHub pull request #1 of commit<PHONE_NUMBER>11, no merge conflicts." -DghprbActualCommit=111111111111 -DghprbPullAuthorLogin=author -DghprbSourceBranch=branch "-DghprbActualCommitAuthor=author author" -DghprbTriggerAuthorLoginMention= "-DghprbPullLongDescription=long description" -DghprbTriggerAuthorEmail= -DGIT_BRANCH=branch '-DghprbPullTitle="renaming XYZ >> 'xyz'"' -DghprbCommentBody=null clean build -Pproperty=property -b build.gradle
The problem resides in this peoperty: '-DghprbPullTitle="renaming XYZ >> 'xyz'"'
That's the pull request title.
With[ '-DghprbPullTitle="renaming XYZ >> 'xyz'"' ] (and with << operator instead of >>) When build is triggered on jenkins, I get the following error:
....
FAILURE: Build failed with an exception.
What went wrong:
Task 'XYZ' not found in root project 'github-project'.
....
With[ '-DghprbPullTitle="renaming XYZ >>> 'xyz'"' ]:
....
bin/gradle: 1: eval: Syntax error: redirection unexpected
....
it is a unix syntax error. Probably jenkinsci(Jenkins) or janinko(ghprb) should care for this issue. But I thought this may help in solving the issue.
With[ '-DghprbPullTitle="aribitraryName >>"' ] (Also unix syntax error):
....
bin/gradle: 1: eval: cannot create : Directory nonexistent
....
Environment
hint:(in win os it works fine.)
os: ubuntu 14.04.4 LTS

Thank you for the well written bug report. This sounds more like a bug in the Jenkins Gradle plugin than in Gradle itself. I think the main problem is that

all build parameters are passed to Gradle as system properties automatically
the given system property contains >> and '.

To check if it is a problem for Gradle itself, could you try passing the property correctly masked on the command line to gradle or gradlew? If this works, please open an issue for the Jenkins Gradle plugin.

executed the same command from cli; I get the same errors.

Yeah, that's what I assumed. The question is how the command got assembled. I suppose that the Jenkins job parameter value is
ghprbPullTitle=renaming XYZ >>> 'xyz'
```,
right?

The Jenkins Gradle plugin converts this to a system property command line expression, in your case:

'-DghprbPullTitle="renaming XYZ >>> 'xyz'"'

This is wrongly quoted for the shell. A possible right quoting would be:

'-DghprbPullTitle="renaming XYZ >> '"'xyz'"'"'
This is not ideal since it passes `"renaming XYZ >> 'xyz'"` as system property while it should probably pass `renaming XYZ >> 'xyz'`. But passing this correctly masked String on the shell to Gradle does not make Gradle fail:

gradle '-DghprbPullTitle="renaming XYZ >> '"'xyz'"'"'

And this would mean that the problem is in the quoting logic of the Jenkins Gradle plugin and not with the Gradle start script. Do you agree?
The problem you are describing has been on my radar: https://github.com/jenkinsci/gradle-plugin/blob/master/src/test/groovy/hudson/plugins/gradle/GradlePluginIntegrationTest.groovy#L204

Yes, That's right. Jenkins job parameter is: ghprbPullTitle=renaming XYZ >>> 'xyz'.
I tried a bunch of possibilities and found the following work as charm:
"-DghprbPullTitle=renaming XYZ >> \'xyz\'" -DghprbPullTitle="renaming XYZ >> \'xyz\'"
this '-DghprbPullTitle="renaming XYZ >> '"'xyz'"'"' doesn't work, I think the system is trying to redirect smthn to a file.
Also it is described in the Java docs:

-Dproperty=value
Sets a system property value. The property variable is a string with no spaces that represents the name of the property. The value variable is a string that represents the value of the property. If value is a string with spaces, then enclose it in quotation marks (for example -Dfoo="foo bar").
And escape special characters or quotations to adhere to the shell syntax.

In the Shell Command Language definition it is stated that:

Enclosing characters in single-quotes (' ') preserves the literal value of each character within the single-quotes. A single-quote cannot occur within single-quotes.

So yeah, I agree it is a ghprb issue.

Please open a bug for Jenkins Gradle plugin in the Jenkins issue tracker. I am closing this issue.

Just for reference: JENKINS-42573


Installer doesn't work after an error

If there is an error in the .env file and you continue the installer. you get an error message in the last step but if you click on exit then if we try again , it doesn't seem to be working. I see that you check for installed file in the storage path but it should be set only if the application has been installed successfully without any errors.

Will be fixed soon!


Microsoft.AspNet.Cryptography.Internal.Test -> Microsoft.AspNet.Cryptography.Internal.Tests, Microsoft.AspNet.Cryptography.KeyDerivation.Test -> Microsoft.AspNet.Cryptography.KeyDerivation.Tests, Microsoft.AspNet.DataProtection.Abstractions.Test -> Microsoft.AspNet.DataProtection.Abstractions.Tests, Microsoft.AspNet.DataProtection.Extensions.Test -> Microsoft.AspNet.DataProtection.Extensions.Tests and Microsoft.AspNet.DataProtection.Test -> Microsoft.AspNet.DataProtection.Tests

According to the guidelines https://github.com/aspnet/Home/wiki/Engineering-guidelines#solution-and-project-folder-structure-and-naming, we should rename the test project to Microsoft.AspNet.Cryptography.Internal.Tests instead of Microsoft.AspNet.Cryptography.Internal.Test, Microsoft.AspNet.Cryptography.KeyDerivation.Tests instead of Microsoft.AspNet.Cryptography.KeyDerivation.Test, Microsoft.AspNet.DataProtection.Abstractions.Tests instead of Microsoft.AspNet.DataProtection.Abstractions.Test, Microsoft.AspNet.DataProtection.Extensions.Tests instead of Microsoft.AspNet.DataProtection.Extensions.Test and Microsoft.AspNet.DataProtection.Tests instead of Microsoft.AspNet.DataProtection.Test

Hi @hishamco, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

See https://github.com/aspnet/EventNotification/pull/12#issuecomment-128427434.


Fix Clang warnings

Description
Fix issues/warnings that arise when compiling with Clang-14.
Test Steps
Built on ubuntu with clang compiler.
Checklist:

[x] I have tested my changes. No regression in existing tests.
[x] I have modified and/or added unit-tests to cover the code changes in this Pull Request.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/bot run uncrustify


Using Python 3.12+?

What's the reason that you don't allow install of Sammo for Python 3.12 and above? Could this be changed?
With Python 3.12.8, I get:
(venv) PS C:> pip install sammo
ERROR: Ignored the following versions that require a different python version: <IP_ADDRESS> Requires-Python >=3.10,<3.12; <IP_ADDRESS> Requires-Python >=3.10,<3.12; <IP_ADDRESS> Requires-Python >=3.10,<3.12; <IP_ADDRESS> Requires-Python >=3.11,<3.12; <IP_ADDRESS> Requires-Python >=3.11,<3.12; <IP_ADDRESS> Requires-Python >=3.11,<3.12; 0.1.4 Requires-Python >=3.11,<3.12; 0.1.6 Requires-Python <3.12,>=3.11; 0.1.7 Requires-Python <3.12,>=3.9; 0.1.8 Requires-Python <3.12,>=3.9; 0.2.0 Requires-Python <3.12,>=3.9; 0.2.1 Requires-Python <3.12,>=3.9; 0.2.4 Requires-Python <3.12,>=3.9; 0.2.6 Requires-Python <3.12,>=3.9; 0.2.7 Requires-Python <3.12,>=3.9; 0.3.1 Requires-Python <3.12,>=3.9
ERROR: Could not find a version that satisfies the requirement sammo (from versions: none)
ERROR: No matching distribution found for sammo
(venv) PS C:> python --version
Python 3.12.8

@kmhansen: It was purely to make sure dependencies don't break while upgrading. I tested and added Python 3.12 support with the newest release.


Fixes for bonnie integration

This PR contains a collection of fixes and code ports from bonnie that were created while working on integrating this into bonnie.
Pull requests into cqm-parsers require the following. Submitter and reviewer should :white_check_mark: when done. For items that are not-applicable, note it's not-applicable ("N/A") and :white_check_mark:.
Submitter:

[ ] This pull request describes why these changes were made.
[ ] Internal ticket for this PR:
[ ] Internal ticket links to this PR
[ ] Code diff has been done and been reviewed
[ ] Tests are included and test edge cases
[ ] Tests have been run locally and pass

Reviewer 1:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

Reviewer 2:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

Codecov Report

Merging #24 into master will increase coverage by 0.16%.
The diff coverage is 88.6%.

@@            Coverage Diff             @@
##           master      #24      +/-   ##
==========================================
+ Coverage   76.36%   76.52%   +0.16%
==========================================
  Files         109      109
  Lines        5229     5274      +45
==========================================
+ Hits         3993     4036      +43
- Misses       1236     1238       +2

Impacted Files
Coverage Δ

lib/hqmf-parser/2.0/document.rb
92.3% <100%> (ø)
:arrow_up:

lib/measure-loader/hqmf_measure_loader.rb
94.73% <100%> (+0.61%)
:arrow_up:

lib/measure-loader/exceptions.rb
100% <100%> (ø)
:arrow_up:

...rser/cql/document_helpers/doc_population_helper.rb
98.83% <100%> (+0.02%)
:arrow_up:

lib/measure-loader/cql_loader.rb
100% <100%> (ø)
:arrow_up:

lib/measure-loader/value_set_helpers.rb
98.18% <100%> (+0.03%)
:arrow_up:

lib/measure-loader/elm_dependency_finder.rb
97.82% <50%> (ø)
:arrow_up:

lib/measure-loader/mat_measure_files.rb
95.34% <69.23%> (+0.05%)
:arrow_up:

lib/measure-loader/vsac_value_set_loader.rb
93.33% <75%> (-6.67%)
:arrow_down:

lib/hqmf-model/types.rb
79.69% <0%> (+0.37%)
:arrow_up:

... and 1 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 0afbc2f...0dfe2c1. Read the comment docs.


Fix typo

Typo: Markdown syntax error. Same as #18514.

@changeworld : Thanks for your contribution! The author, @jamesbak, has been notified to review your proposed change.


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/26538

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/28068

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/28068

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/29263

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/29479

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/29901

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/29939

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/35710

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/83310

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/111580


Add Makefile support  --mcpu=native as override FLAGS to permit build crystal compiler can enable this option optional for a better performance.

As discuss in this forum link.
Add --mcpu-=native give me a really better performance on my local AMD 7840hs laptop.
Following is the explanation for --mcpu  or --‑mtune in the arm community

GNU and LLVM compilers support passing the special parameter value “native” to these flags.  The “native” value tells the compiler to detect the architecture and/or microarchitecture of the machine on which the compiler is executing and use that (micro)architecture as the parameter to -march, -mtune, or -mcpu as appropriate.  Assuming architecture detection works for your platform, passing “native” is usually the best choice if you’re not cross-compiling and all you care about is performance.[3]  With the GNU compiler, all three flags can accept “native” as a parameter so -march=native, -mtune=native, and -mcpu=native are all valid.  LLVM compilers only support “native” for the -mcpu and -mtune flags.  You cannot use -march=native with LLVM-based compilers.  If you’re not cross-compiling, always use -mcpu=native to maximize optimization and compatibility across compilers.
On Arm, if you want to optimize for both a particular architecture and microarchitecture then you use the -mcpu flag.  This is different from x86, where -mcpu is a deprecated synonym for ‑mtune.  The -mcpu flag accepts the same parameter values as the -mtune flag.  For example, -mcpu=thunderx2t99 is correct but ‑mcpu=armv8.1-a is not.  Figure 4 shows the execution and optimization spaces of a binary compiled with -mcpu=thunderx2t99.  In this case, the binary could execute on anything implementing the v8.1 architecture or better, but it has been optimized for execution on the ThunderX2.

I am not an expert in this area, in fact, I am quite lacking knowledge about this area. but I think adding --mcpu=native when compiling the Crystal compiler on the local machine, and the compiler only be used on the local machine too, it should be a good idea, and i have been built a Crystal compiler on my Arch linux locally with --mcpu=native enabled, and then built a lucky project use this new compiler,   and deploy it into production, it has been working well so far.
So, i propose to add support for this in the Makefile use a optional flag, if this is acceptable, i will create a PR for this.
Sure, as I said, because not familiar with this tune, there may be some things that were lack considered.
Thanks.

Would it actually be common enough of an option to really make it that much easier vs just doing like FLAGS=--mcpu=native make?

Would it actually be common enough of an option to really make it that much easier vs just doing like FLAGS=--mcpu=native make?

Oh, no, really?
I don't know we can use FLAGS like this, i thought we have to add a flag to make this option work, e.g. native=1.

FLAGS=--mcpu=native make

Cool, it works, i forget i can pass flags use env, feel free to close this issue if people thought this option is not important.


Added support for 3 second timeout on code execution.

Tested manually and autotested.

Thanks! LGTM.

Not sure why cla/google check isn't triggering. Closing and reopening to try and activate it.


[Bug]: Potential geofilter issue

Checked for duplicates
Yes - I've already checked
Describe the bug
@niarenaw is reporting a potential geofilter bug. For the SLC granule S1A_IW_SLC__1SDV_20160728T225204_20160728T225231_012355_0133F4_8423.zip the logs seem to indicate that it's passing the filter. But it shouldn't be
{ "type": "FeatureCollection", "features": [{ "type": "Feature", "properties": { "type": "S2", "identifier": "10TFP" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -121.7475191278, 44.2465509345, 0.0 ], [ -120.3733540263, 44.2232097399, 0.0 ], [ -120.4161917204, 43.2356009597, 0.0 ], [ -121.7679673, 43.2581553186, 0.0 ], [ -121.7475191278, 44.2465509345, 0.0 ] ] ] ] } }] }
[2024-04-23 20:19:26,928: INFO/_post] Document updated: {'_index': 'slc_spatial_catalog-2024.04', '_type': '_doc', '_id': 'S1A_IW_SLC__1SDV_20160728T225229_20160728T225256_012355_0133F4_4649-SLC', '_version': 1, 'result': 'created', '_shards': {'total': 2, 'successful': 1, 'failed': 0}, '_seq_no': 378, '_primary_term': 2}
[2024-04-23 20:19:26,928: INFO/does_bbox_intersect_region] bbox=[{'lat': 46.255867, 'lon': -76.713303}, {'lat': 44.639988, 'lon': -76.258331}, {'lat': 45.03212, 'lon': -73.094223}, {'lat': 46.648479, 'lon': -73.453896}, {'lat': 46.255867, 'lon': -76.713303}]
[2024-04-23 20:19:26,975: INFO/does_bbox_intersect_region] is_bbox_in_region=True
[2024-04-23 20:19:26,977: INFO/log_request_success] POST http://<IP_ADDRESS>:9200/slc_catalog*/_search?size=1000 [status:200 request:0.002s]
[2024-04-23 20:19:26,978: INFO/log_request_success] POST http://<IP_ADDRESS>:9200/slc_catalog*/_search?size=1000&from=1000 [status:200 request:0.001s]
[2024-04-23 20:19:26,978: INFO/update_document] update_document **kwargs
[2024-04-23 20:19:26,981: INFO/log_request_success] POST http://<IP_ADDRESS>:9200/slc_catalog-2024.04/_update/S1A_IW_SLC__1SDV_20160728T225204_20160728T225231_012355_0133F4_8423.zip-r15 [status:201 request:0.003s]
[2024-04-23 20:19:26,982: INFO/log_request_success] POST http://<IP_ADDRESS>:9200/slc_spatial_catalog*/_search?size=1000 [status:200 request:0.001s]
[2024-04-23 20:19:26,984: INFO/log_request_success] POST http://<IP_ADDRESS>:9200/slc_spatial_catalog*/_search?size=1000&from=1000 [status:200 request:0.001s]
[2024-04-23 20:19:26,987: INFO/log_request_success] PUT http://<IP_ADDRESS>:9200/slc_spatial_catalog-2024.04/_doc/S1A_IW_SLC__1SDV_20160728T225204_20160728T225231_012355_0133F4_8423-SLC [status:201 request:0.003s]
[2024-04-23 20:19:26,987: INFO/_post] Document updated: {'_index': 'slc_spatial_catalog-2024.04', '_type': '_doc', '_id': 'S1A_IW_SLC__1SDV_20160728T225204_20160728T225231_012355_0133F4_8423-SLC', '_version': 1, 'result': 'created', '_shards': {'total': 2, 'successful': 1, 'failed': 0}, '_seq_no': 392, '_primary_term': 2}

What did you expect?
nt
Reproducible steps
1.
2.
3.
...

Environment
- Version of this software [e.g. vX.Y.Z]
- Operating System: [e.g. MacOSX with Docker Desktop vX.Y]
...

This is not a bug. Geofiltering only works in historical processing mode and the user did not specify that mode


[8.x] Adds global eloquent type casters

This PR adds feature for declaring type caster in global space.
Model::castUsing(Uuid::class, new class() implements CastsAttributes {
    //...
});

class MyModel extends Model {
    public $casts = [
        'uuid' => Uuid::class,
    ];
}

In this case no need to make caster class or modify(extending) vendor classes like Uuid or Enums.
Also can add autobinding internal casting types
Model::castUsing(ArrayObject::class, function ($arguments) {
    return AsArrayObject::castUsing($arguments);
});

So in your first example where you did castUsing(Uuid::class... ... where is the Uuid class?

This may be any class. castUsing provide caster for any class or just cast name. See tests in PR.

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


How to pass HTMLElement to iFrameResize?

Hi!
Is it possible to pass an HTMLElement to iFrameResize? The CSS selector doesn't work with Blazor, unfortunately. However, it is possible to pass an HTMLElement to a javascript function in Blazor, so that would be a great workaround.
Thanks!

Yeah just send as the second parameter instead of the selector


Remove client-server shortcut paste code

Fixes #1839
@jsorg71 - I'd appreciate your feedback on this PR. Are I missing something obvious?
When significant amounts of data is coming from the client in a fragmented CLIPRDR_DATA_RESPONSE PDU, this code provides a way to start copying it to a requesting client before it is all read.
The only advantage of this code is to provide a slight speedup before a paste is visible on the server.
There are significant problems with this code. Notably, it is very difficult to parse Unicode text coming through this route. Each UTF-16 character can occupy up to 4 bytes, and a fragmentation boundary could occur at any point within a UTF-16 character.

In the absence of any feedback I'm going to merge this change as it fixes a customer problem. Happy to revert if it proves necessary.

Hi Matt,  Sorry for delay,
I think you can see what this ss code was doing.  The clipboard channel chunks out clipboard data to transmit, the X11 clipboard chunks out data to transfer between X11 clients.  Hook them up so the app starts getting data right away.  Seems great except you need to know the size in the beginning and converting UTF 16 to UTF 8 you can not know the size.  I did notice you can guess the size too small but guessing too large hangs X.  We could get around that by dumping zeros at the end maybe.
I think it's ok to just remove it.  If we need something like this back, we can improve on it.

I got the gist of the code. The main problem I had was more related to #2603 rather than the size. Addressing #2603 means coping with UTF-16 characters being either 2 or 4 bytes (e.g. 😥 maps to 0x3d 0xd8 0x25 0xde in the byte stream). Converting that to UTF-8 on the fly in the ss code means caching up to 3 bytes potentially when we hit a fragmentation point. It's doable, but messy.


Sieve of Eratosthenes

Have added functions in Python, C++ and Java  to implement the algorithm of " Sieve of Eratosthenes" .
RoadMap.md has been checked and updated with the hyperlink of the above contribution.

Good work


AWS IoT SDK Support

I have enabled X-Ray tracing for a lambda function using the AWSSDKHandler.RegisterXRayForAllServices() method of the X-Ray SDK (before instantiating any SDK clients). Nuget AWSXRayRecorder.Handlers.AwsSdk (v2.8.3) was installed. It is now recording DynamoDB calls in my service map for me, but I noticed that none of the AWS IoT SDK calls are displaying in the service map. Is this not supported yet? Visibility to these service calls would be fantastic for us to have in our observability strategy.

Hi @napalm684
The AWSSDKHandler.RegisterXRayForAllServices() API is to instrument all the clients for AWS SDK only. AWS IoT SDK is not supported yet. Currently, we don't have it on our roadmap so it's difficult to say when would it be supported.
If you consider using OpenTelemetry for your lambda application, then I would recommend you open a feature request here as it has great support for existing instrumentations and for adding more library instrumentations as well.
Thanks!

Hi @srprash
Is AWS recommending we move away from AWS X-Ray SDK towards OpenTelemetry for all observability needs in the future?
It is disappointing that the IoT core support in the AWS SDKs doesn't seem to have feature parity with other language/development platforms. Is there some motivation behind this (i.e.: not many customers using .NET for IoT implementations)?

Is AWS recommending we move away from AWS X-Ray SDK towards OpenTelemetry for all observability needs in the future?

We are recommending that customers try out the AWS Distro for OpenTelemetry if they're looking for new instrumentations, since OTel has a much larger collection of supported libraries/frameworks for instrumentation due to their larger community and first-class X-Ray support. Generally speaking there is more bandwidth for such new features from the OTel community.
Regarding the lack of IoT support, unfortunately I don't think the X-Ray team has much knowledge here, you may need to ask on an AWS IoT repo or forum if possible.

I will reach out to our enterprise support team. Thanks for letting me know @willarmiros .

@willarmiros  Is there still no out of the box support by AWS IOT core for open telemetry , especially to support w3c trace ids for iot core and connected la`bmdas?
https://w3c.github.io/trace-context-mqtt/#json-payload


Prefixes policy's name in evaluator's fail messages

We suggest to include the policy's name in evaluator's fail messages.
Recently, we had a case where the admission webhook denied resource creation due to one of our policy definitions not returning anything.
It was hard to analyze which policy was causing this error:
Error: admission webhook "webhook.bridgekeeper.k8s" denied the request: Validation function did not return expected types

Implemented in https://github.com/MaibornWolff/bridgekeeper/commit/460739241292dfcefd3353c33fc8851962f4fe69
Closing this PR


[frontend] [ops golf?] Pass collector URL to frontend via reverse proxy.

This fixes the current problem of the collector URL not being passed into the frontend, as Next.JS will not pass env vars into the client except ones known at build time.
It accomplishes this by way of establishing a reverse proxy that serves the Next.JS app (best practice!) and uses it to set a cookie that the client code reads on load.

@puckpuck had an excellent idea to use envoy rather than nginx. there is one small catch here, that we have to build an envoy container in order to get envsubst but that's probably not the end of the world.
Someone more enterprising than I can enable tracing/metrics off this post v1.

The frontend is broken on my machine? Is port 8080 still the right connection or do I need to navigate to the reverse proxy?

If we update the docker file to port 80 we should be good

changelog

If we update the docker file to port 80 we should be good

what part of the dockerfile? the compose file or the frontend?

We need to update the readmes to indicate we run on port 80 now

Updated the docker readme with the current state

Not for this PR, but it would be nice if there is a way to force mermaid to not draw a box in the top right corner that gets covered by the github icons


Azure App Configuration Push doesn't exist

The task described in this article ("Azure App Configuration Push") doesn't exist

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 0e1bd2ea-0594-5d07-2dbe-b5d9b0339e98
Version Independent ID: dcacbdc8-722a-9acd-e5b8-f2fa9464bb6e
Content: Push settings to App Configuration with Azure Pipelines
Content Source: articles/azure-app-configuration/push-kv-devops-pipeline.md
Service: azure-app-configuration
GitHub Login: @maud-lv
Microsoft Alias: malev

@dlightfoot61
Thanks for your feedback! We will investigate and update as appropriate.

Actually, I see it's in the marketplace and not in there by default. You might want to note that in the article.

Or make it in the available list by default (even better).

Hi, I reviewed the article and see that the following is listed in the prerequisites: "Azure App Configuration Push task - download for free from the Visual Studio Marketplace.". I think that should cover it. Thank you for the suggestion! #please-close


bug/docs: CDK-Pipeline children cannot be suppressed without first running buildPipeline()

What is the problem?
NOTE: This could easily be considered a documentation problem, but for the sake of thoroughness I'm filing it as a bug.
When attempting to suppress elements of a CDK Pipeline, specifically one from the aws-cdk-lib/pipelines package, an error is thrown unless .buildPipeline() is called before the suppressions are applied.
Reproduction Steps
Clone this example repo and attempt to yarn cdk synth.
You should receive this error:
Error: Suppression path "/example-cdk-pipeline/DummyPipeline/Pipeline/ArtifactsBucket/Resource" did not match any resource. This can occur when a resource does not exist or if a suppression is applied before a resource is created.

The fix is simple: uncomment the dummyPipeline.buildPipeline() call in src/Pipeline/DummyPipeline.ts. After this, it will suppress as intended.
What did you expect to happen?
I was expecting the suppressions to be applied as expected.
What actually happened?
This error is thrown:
Error: Suppression path "/example-cdk-pipeline/DummyPipeline/Pipeline/ArtifactsBucket/Resource" did not match any resource. This can occur when a resource does not exist or if a suppression is applied before a resource is created.

cdk-nag version
2.14.46
Language
Typescript
Other information
I don't necessarily think it's on Cdk-Nag to fix this "issue", but adding a more helpful annotation and/or section to the readme on what exactly is meant by the below text snippet would be very helpful.
This can occur when a resource does not exist or if a suppression is applied before a resource is created.

I was stuck on this for a little bit until someone else who happened to know about .buildPipeline() came along and pointed out the issue.

For context, this is related to https://github.com/aws/aws-cdk/issues/18440.
Happy to take a PR for improving the documentation!

@dontirun I'll try and take stab this week!


binary-search-tree: fix test for deleting root node

In the moment it is possible to pass the tests even if the deletion of the root node is not handled correctly.
One part is that the value of the root node is replaced but we also need to make sure that the node the value comes from is actually deleted from the tree.
Let me explain a bit more what I mean.
In the particular test case, we construct a tree that looks like:
  5
 /
2

Now we delete 5 and want to obtain
  2

But we currently do not check if we may obtain something like:
  2
 /
2

I admit that this may not be an obvious case but since this happened to a student I'm currently mentoring, I thought that it may be useful to add this check to the test case.
Let me know what you think :)

Pinging @exercism/reviewers


feat: infallible construction of field elements

Pull Request type

Please add the labels corresponding to the type of changes your PR introduces:

Bugfix
Feature
Code style update (formatting, renaming)
Refactoring (no functional changes, no API changes)
Build-related changes
Documentation content changes
Testing
Other (please describe):

What is the current behavior?

Resolves: #NA
What is the new behavior?

Does this introduce a breaking change?

Other information

Moved the PR against starkware-io.


Request spec (RSpec-Rails) returns "The required parameter, data, is missing."

I'm trying to test my API with an RSpec-Rails request spec. Here's the spec:
    # logged_in_headers is defined above

    describe "POST /create" do
      it "creates a new campaign" do
        post "/api/v2/campaigns", { "data" => {} }, logged_in_headers
        expect(JSON.parse(response.body)).to eq({ not_sure: "what" })
      end
    end

I'm getting this error:
  1) /api/v2/campaigns logged in POST /create creates a new campaign
     Failure/Error: expect(JSON.parse(response.body)).to eq({ not_sure: "what" })

       expected: {:not_sure=>"what"}
            got: {"errors"=>[{"title"=>"Missing Parameter", "detail"=>"The required parameter, data, is missing.", "id"=>nil, "href"=>nil, "code"=>106, "path"=>nil, "links"=>nil, "status"=>"bad_request"}]}

       (compared using ==)

       Diff:
       @@ -1,2 +1,2 @@
       -:not_sure => "what"
       +"errors" => [{"title"=>"Missing Parameter", "detail"=>"The required parameter, data, is missing.", "id"=>nil, "href"=>nil, "code"=>106, "path"=>nil, "links"=>nil, "status"=>"bad_request"}]

It appears the params is not passing through when we're posting. Any ideas?

Could be related to the fact I'm on Rails 3.2. See issue #152.

To be a valid JSON-API request you need to at least have the "type" attribute set in the data object, so I believe your request should give an error of some kind.
There is something funny going on with blank data requests though - it seems like attributes whose values are empty are getting discarded altogether - I have a POST endpoint I'd like to work without requiring any parameters at all but I'm not able to get a "data": {"type": "tokens"} request to complete properly. It works fine if I add just an id.
Additionally, I tried to see if I could replicate your issue and I succeeded on Rails 4.2. When I add a "type" attribute, though, it returns 201 and fires my after_create callbacks even though the model didn't save correctly.

The request is certainly invalid, but the error message doesn't look like what we should be returning in that case. However it's returned that way under Rails 4 as well. I'll look into what's going on soon.

Looks like it's coming from https://github.com/cerebris/jsonapi-resources/blob/master/lib/jsonapi/request.rb#L49, which is using strong parameters. It's failing because there is no content.
Having thought about it for a few more minutes I'm not actually sure the empty request is actually invalid. I'll see if I can fix it so an empty data is acceptable and then it's up to your model validation as to whether it's a valid operation.

Thanks for the help, @adamworrall and @lgebhardt. I updated the spec with the "type" and am getting a new error:
    describe "POST /create" do
      it "creates a new campaign" do
        post "/api/v2/campaigns", { "data" => { "type" => "campaign" } }, logged_in_headers
        expect(JSON.parse(response.body)).to eq({ not_sure: "what" })
      end
    end

Error:
     Failure/Error: post "/api/v2/campaigns", { "data" => { "type" => "campaign" } }, logged_in_headers
     JSON::ParserError:
       757: unexpected token at 'data[type]=campaign'

Any ideas?

@jamonholmgren try encoding your body hash as JSON? If that works, you should run into the problem I mentioned earlier. #153 should fix that.

Okay, we're getting somewhere @adamworrall !
    describe "POST /create" do
      it "creates a new campaign" do
        post "/api/v2/campaigns", { "data" => { "type" => "campaign", "name" => "test campaign" } }.to_json, logged_in_headers
        expect(JSON.parse(response.body)).to eq({ not_sure: "what" })
      end
    end

Now I get:
{"errors"=>[{"title"=>"Invalid resource", "detail"=>"Campaign is not a valid resource.", "id"=>nil, "href"=>nil, "code"=>101, "path"=>nil, "links"=>nil, "status"=>"bad_request"}]}

I for sure have a Campaign resource.
class Api::V2::CampaignResource < JSONAPI::Resource
  attributes :id, :name
end

Ah, it was supposed to be "type" => "campaigns" (plural). Working now!
I submitted a PR for preliminary Rails 3.2 support ( #156 ), so I think we can consider this closed.

Types are always plural in JSON API. You have it as singular "campaign".
Also, you don't need the :id in attribute, which is a new fix. :id is now always included. But it doesn't hurt to have it.
I'm not sure if you caught it, but I released a new version that includes #153

What timing. Glad you figured it out. I'll look into the PR. Thanks.

:+1:

Having a similar problem, in RSpec
      it "returns 201 with corresponding location" do
        request.env['CONTENT_TYPE'] = 'application/vnd.api+json'
        post :create, '{ "data": { "type": "concepts", "attributes": { "description": "Lorem ipsum" } } }',
             valid_session
        expect(response.status).to eq(201), "Request #{valid_attributes.to_json} failed: #{response_body}"
        expect(response.location).to eq(v1_concept_url(Concept.last))
      end

produces
  3) V1::ConceptsController POST #create with valid params returns 201 with corresponding location
     Failure/Error: expect(response.status).to eq(201), "Request #{valid_attributes.to_json} failed: #{response_body}"
       Request {"data":{"type":"concepts","attributes":{"description":""}}} failed: {"errors"=>[{"title"=>"Missing Parameter", "detail"=>"The required parameter, data, is missing.", "id"=>nil, "href"=>nil, "code"=>106, "path"=>nil, "links"=>nil, "status"=>"bad_request"}]}
     # ./spec/controllers/v1/concepts_controller_spec.rb:58:in `block (4 levels) in <top (required)>'

But the same request using the Postman app seems to work just fine. Any ideas how to fix this?

You have quotes wrapped around the payload. I'm not using RSpec, but that should probably be a hash.
it "returns 201 with corresponding location" do
        request.env['CONTENT_TYPE'] = 'application/vnd.api+json'
        post :create, { "data": { "type": "concepts", "attributes": { "description": "Lorem ipsum" } } },
             valid_session
        expect(response.status).to eq(201), "Request #{valid_attributes.to_json} failed: #{response_body}"
        expect(response.location).to eq(v1_concept_url(Concept.last))
      end

Well that was embarrassing. Haha works now, thanks a lot :)


Update README.md

What was the change?
Updated readme file to include the quickstart section from the docs
Why was the change necessary?
The quickstart section was empty in the readme file
please let me know if I have to make any changes

That was per design. We have buttons that forwards to different quick starts


Some map tiles are loaded over http

Hi, I was tuning CSP server side, and noticed that some tiles are loaded over http:
Content Security Policy: The page’s settings blocked the loading of a resource at http://tile.stamen.com/watercolor/10/504/341.jpg (“img-src”).
This is for "Terrain" and "Watercolor" layers. Since I'm enforcing https everywhere, would it be possible to load those tiles using https ?
It seems like there's a certificate issue with https://tile.stamen.com, but found this on their github repository: https://github.com/stamen/maps.stamen.com/pull/126/commits/a84c1d8e8f64f333c91a081de8c6e37d50d9ebf6

Yes should be possible.

pushed fix as version 1.5.26


new taxonomy management interface

Problems with the current management ui:

Taxonomy overview doesn't load: https://de.serlo.org/taxonomy/term/organize-all
Sorting taxonomy elements doesn't work

Possible solution: create new management interface with already existing views:

show only two level of taxonomy with taxonomy-view for learners
move taxonomy like moving a learning object by naming a new parent uuid
sort taxonomy with the "sort elements" view

@arekkas do you agree with the issue description?

Yes, I think we should reuse most of the code from the original views here. we can probably load up to ~5-10 levels (probably needs some experimenting) deep so it's a bit easier to get an overview

BTW: https://de.serlo.org/taxonomy/term/get/3


fixed lists; removed sitemultiplier

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

BingAds/hotel-service/get-started.md
:white_check_mark:Succeeded

BingAds/hotel-service/reference.md
:white_check_mark:Succeeded

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


1.21

1.21 support is needed now, and just changing the fabric mod json doesn't work.

This mod hasn't been properly updated in a year. I'm borderline about to fork it and update it myself.

This mod hasn't been properly updated in a year. I'm borderline about to fork it and update it myself.

Tbh please do, I would appreciate it.

This mod hasn't been properly updated in a year. I'm borderline about to fork it and update it myself.

any updates on that idea?

If you do, let me know. I manage a modpack for blindness accessibility mods, and cloth config isn't accessible, which means that the sodium settings menu doesn't work for screen readers. So people have to use shift+P to get to the vanilla menu every time they open the video settings menu, which some people are confused about.

Apologies guys, I have been super busy recently 😬. Have been meaning to do it for a while now however been stuck doing assessments constantly for school.

This mod hasn't been properly updated in a year. I'm borderline about to fork it and update it myself.

any updates on that idea?

I've been thinking about it recently. I mean, if the original guy is gonna do it soon, I'd rather not waste my time, but I would be more than happy to figure out how to update it. Maybe even add config options for the button layout.

Updated


Signup layout has changed

There's a revert in design, it doesnt look like it used to be
In signup when keyboard is up it should not squash the content and keyboard should be shown over content.
Definition of Done

[x] content not squeezed when keyboard is up
[x] line width of all inputs should match the design
[x] line position of all inputs should be the same, ie when going from one signup form to the other the line vertical position should stay the same
[x] the space that we added in the middle of the sms/email code is missing again

![792](https://user-images.githubusercontent.com/36693645/67958650-2b68d180-fc00-11e9-8945-31fe4bdca7ba.gif)

Checked on Dev, QA and eWallet environments
Look as per requirements
eWallet Env:
https://www.dropbox.com/s/93nro0rlc3pp7tl/1.jpg?dl=0
https://www.dropbox.com/s/m2ocb1ep03bpfg7/2.jpg?dl=0
https://www.dropbox.com/s/99e35zlunl9puhi/3.jpg?dl=0
https://www.dropbox.com/s/oi6e7jtq63k874u/4.jpg?dl=0
https://www.dropbox.com/s/py1p1smaj8e58w7/5.jpg?dl=0
https://www.dropbox.com/s/o91c8xttyydt1m3/6.jpg?dl=0
https://www.dropbox.com/s/i7hp18hhivpuwqo/7.jpg?dl=0

Checked on eWallet environments
Work as per requirements / Look as per requirements


Eliminate Hand-Rolled Cryptography

This is a meta-issue to figure out how to eliminate various forms of hand-rolled crypto from the Python atproto ecosystem, both in this repo, and in general.
A quick summary of the relevant areas of cryptography in atproto (official docs)

Asymmetric keys are either secp256k1 ("bitcoin flavour") or secp256r1 (aka NIST-P256)
Signatures for both key types use the ECDSA algorithm in conjunction with SHA256,

In "low-S" form as described in bitcoin BIP-0062
Serialised to bytes in "raw/compact*" format, which is 32 big-endian bytes of "r", followed by 32 big-endian bytes of "s"

*I don't think this format has a standard name! It's quite common though, for example, it's used internally to JWT
There are python bindings for secp256k1 libraries that handle these constraints internally (e.g. https://pypi.org/project/secp256k1/, due to its use in the Bitcoin world) , but I don't think there are existing solutions out there for producing low-S NIST-P256 signatures.
For that reason, and because I like pyca/cryptography, I adapted it to this use-case like so. As noted in the comments, this is a bit of a hack, and my hacks have since been incorporated into other Python projects in the atproto ecosystem. This isn't very good! We need to solve this properly, which either means writing some kind of "atproto crypto" wrapper library, or getting the needed features upstreamed. Since pyca/cryptogrphy depends on openssl, this might mean contributions to openssl.
Signature Serialisation
First, what is the format even called? Raw? Compact? IDK!
It could be a new pyca/cryptography feature, in the cryptography.hazmat.primitives.asymmetric.utils module (alongside encode_dss_signature and decode_dss_signature)
pyjwt already implements compatible logic inside jwt.utils https://github.com/jpadilla/pyjwt/blob/12420204cfef8fea7644532b9ca82c0cc5ca3abe/jwt/utils.py#L77-L96 (der_to_raw_signature and raw_to_der_signature respectively). Maybe these methods could be upstreamed into pyca/cryptography as-is? It would be a very uninvasive change.
Low-S enforcement
Assuming the der_to_raw_signature and raw_to_der_signature helper functions are adopted, they could be extended with a boolean flag that indicates whether Low-S should be enforced. The low-S-ness could be considered a serialisation detail, after all.
mockup: (based on jwt.utils linked above)
def der_to_raw_signature(der_sig: bytes, curve: "EllipticCurve", to_low_s: bool) -> bytes:
    num_bits = curve.key_size
    num_bytes = (num_bits + 7) // 8

    r, s = decode_dss_signature(der_sig)

    if to_low_s and s > curve.group_order // 2:
        s = curve.group_order - s

    return number_to_bytes(r, num_bytes) + number_to_bytes(s, num_bytes)

def raw_to_der_signature(raw_sig: bytes, curve: "EllipticCurve", from_low_s: bool) -> bytes:
    num_bits = curve.key_size
    num_bytes = (num_bits + 7) // 8

    if len(raw_sig) != 2 * num_bytes:
        raise InvalidSignature("Invalid signature length")

    r = bytes_to_number(raw_sig[:num_bytes])
    s = bytes_to_number(raw_sig[num_bytes:])

    if from_low_s and s > curve.group_order // 2:
        raise InvalidSignature("Invalid signature (high-S)")

    return bytes(encode_dss_signature(r, s))

The big blocker on this is that EllipticCurve.group_order isn't a thing. My current implementation hardcodes a lookup table - ideally, pyca/cryptography could provide this information itself (which probably means openssl needs to expose it, too)
Edit: EC_GROUP_get_order is a thing https://www.openssl.org/docs/man3.0/man3/EC_GROUP_get_order.html

This patch would avoid the need to hard-code curve group orders https://github.com/pyca/cryptography/compare/main...DavidBuchanan314:cryptography:expose-group-order

upstreamed group order constants coming soon: https://github.com/pyca/cryptography/pull/12113


Salesforce/sfdx project container

This adds a dev container definition for sfdx based on the dockerhub container salesforce/salesforcedx with additional extensions defined in devcontainer.json.  I didn't include a test-project directory because we have separate test coverage for salesforce/salesforcedx.

@vazexqi Great - Happy to review a PR (or just make the change if easier).

Thanks for the tip.  I just submitted a new PR with this property set.


Maps as swagger:parameters

Hi,
I'm using go-swagger to generate my Swagger docs from code, and I came across a problem with a given parameter.
When I annotate a given struct that has a map[KeyType]OtherKeyType with swagger:parameters, it returns items doesn't support maps. I can tell the current version may not support maps  in the parameter delcaration, but I'm writing to (i) know if this feature may be inline for release (ii) know if there is any workaround for declaring maps in parameter structs.
Thanks in advance and congrats for the great work,
Renato Vieira
go-swagger version: 0.8.0
go version:1.7.4
OS: Ubuntu 16.04

Can you provide examples

in non-body parameters maps are not supported in the swagger spec.
In the body json schema only allows maps with string keys


what KAN I say?

Man!

lamo

If u need help, contact with me please. I'm really interested in KAN!


Explore ceph-ansible for ideas

https://github.com/ceph/ceph-ansible aims to do for Ceph something akin to what I'm trying to do here for Kubernetes, but has had a lot more work done on it by folks that know more than me about both Vagrant and Ansible.

Fabric8 also have a Vagrantfile to get up and running with a single guest VM: http://fabric8.io/guide/getStartedVagrant.html


fix(page): Don't pollute _G with parameters when rendering a page

Small fix discussed on gitter yesterday

Coverage decreased (-0.01%) to 82.666% when pulling 38f9f493a8ded32c5c8191cb6b2f2eaf4956336a on mpeterv:fix-page-globals into 3bff1814d6f973eeb27aef1ce08618d58fcb5361 on sailorproject:master.

Coverage decreased (-0.01%) to 82.666% when pulling 38f9f493a8ded32c5c8191cb6b2f2eaf4956336a on mpeterv:fix-page-globals into 3bff1814d6f973eeb27aef1ce08618d58fcb5361 on sailorproject:master.

Coverage decreased (-0.01%) to 82.666% when pulling 38f9f493a8ded32c5c8191cb6b2f2eaf4956336a on mpeterv:fix-page-globals into 3bff1814d6f973eeb27aef1ce08618d58fcb5361 on sailorproject:master.

fantastic 💃


google-chrome: add /run/opengl-driver/share/vulkan/icd.d/ to path

Motivation for this change
NixOS stores ICDs at  /run/opengl-driver/share/vulkan/icd.d/, while Chrome is searching these paths:
DRIVER: Searching for driver manifest files
DRIVER:    In following folders:
DRIVER:       /home/bweeks/.config/vulkan/icd.d
DRIVER:       /etc/xdg/vulkan/icd.d
DRIVER:       /home/bweeks/.nix-profile/etc/xdg/vulkan/icd.d
DRIVER:       /etc/profiles/per-user/bweeks/etc/xdg/vulkan/icd.d
DRIVER:       /nix/var/nix/profiles/default/etc/xdg/vulkan/icd.d
DRIVER:       /run/current-system/sw/etc/xdg/vulkan/icd.d
DRIVER:       /etc/vulkan/icd.d
DRIVER:       /home/bweeks/.local/share/vulkan/icd.d
DRIVER:       /nix/store/z4p55yy4i15l5cppid37yih6gvrbczvy-cups-2.3.3op2/share/vulkan/icd.d
DRIVER:       /nix/store/ydckdz6qc010fclx3hrksa62yjphrl19-gtk+3-3.24.30/share/vulkan/icd.d
DRIVER:       /nix/store/zszg84zmq95fmka2xmb29j80p8y8671j-adwaita-icon-theme-41.0/share/vulkan/icd.d
DRIVER:       /nix/store/6pwg357yyh43aklmxnh2zlwi21dbwfv2-hicolor-icon-theme-0.17/share/vulkan/icd.d
DRIVER:       /nix/store/0rhbw783qcjxv3cqln1760i1lmz2yb67-gsettings-desktop-schemas-41.0/share/gsettings-schemas/gsettings-desktop-schemas-41.0/vulkan/icd.d
DRIVER:       /nix/store/ydckdz6qc010fclx3hrksa62yjphrl19-gtk+3-3.24.30/share/gsettings-schemas/gtk+3-3.24.30/vulkan/icd.d
DRIVER:       /nix/store/hnnlhlsn0qbf166b88kr5kynq4dxal13-patchelf-0.13/share/vulkan/icd.d
DRIVER:       /nix/store/jbi6kbiilbg7mxy2y8ydklbgz7r8iyqj-desktops/share/vulkan/icd.d
DRIVER:       /home/bweeks/.nix-profile/share/vulkan/icd.d
DRIVER:       /etc/profiles/per-user/bweeks/share/vulkan/icd.d
DRIVER:       /nix/var/nix/profiles/default/share/vulkan/icd.d
DRIVER:       /run/current-system/sw/share/vulkan/icd.d

Tested by running VK_LOADER_DEBUG=all google-chrome-unstable --enable-features=Vulkan and navigating to chrome://gpu.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

So I assume Google Chrome doesn't use the wrapped Vulkan loader from NixOS then?
Just do be sure: Does vulkaninfo from the vulkan-tools package run fine on your system (without overriding any environment variables)?
Adding this workaround for Google Chrome is not ideal (e.g. that path might change at some point: https://github.com/NixOS/nixpkgs/issues/141803) but I guess we can merge it if necessary. The commit message needs to be improved (adding the relevant information from your PR description to the body) before merging but I can also handle that via GH's squash and merge (out of laziness).
Looking at the driver discovery documentation for Linux it seems like $XDG_DATA_DIRS is indeed the most appropriate option: https://github.com/KhronosGroup/Vulkan-Loader/blob/60d17fe6c65befa0a738b6c33da2eb0670055f3b/docs/LoaderDriverInterface.md#driver-discovery-on-linux
The NixOS documentation (just for reference): https://nixos.org/manual/nixos/unstable/index.html#sec-gpu-accel-vulkan
Anyway, thanks for looking into it!

So I assume Google Chrome doesn't use the wrapped Vulkan loader from NixOS then?

That appears to be the case. As far as I can tell vulkan-loader is part of libvulkan.so.1 that is shipped with Chrome. Also, removing the vulkan-loader bits has no effect.

Just do be sure: Does vulkaninfo from the vulkan-tools package run fine on your system (without overriding any environment variables)?

Yup, vulkaninfo looks good on my machine.

Adding this workaround for Google Chrome is not ideal (e.g. that path might change at some point: #141803) but I guess we can merge it if necessary. The commit message needs to be improved (adding the relevant information from your PR description to the body) before merging but I can also handle that via GH's squash and merge (out of laziness).

Instead of hard coding the path, I now use the path defined by addOpenGLRunpath, which is the same path the system vulkan-loader package uses.

Looking at the driver discovery documentation for Linux it seems like $XDG_DATA_DIRS is indeed the most appropriate option: https://github.com/KhronosGroup/Vulkan-Loader/blob/60d17fe6c65befa0a738b6c33da2eb0670055f3b/docs/LoaderDriverInterface.md#driver-discovery-on-linux
The NixOS documentation (just for reference): https://nixos.org/manual/nixos/unstable/index.html#sec-gpu-accel-vulkan
Anyway, thanks for looking into it!