Eliminators and Typeclasses

I am wondering whether Eliminators can help prove that this is valid:
I have a normal HList:
data HList (ts :: [Type]) where
    HNil :: HList '[]
    (:&:) :: t -> HList ts -> HList (t ': ts)

infixr 5 :&:

instance (Show (HList '[])) where
    show _ = "[]"

instance (Show a, Show (HList ts)) => (Show (HList (a : ts))) where
    show (a :&: rest) = show a ++ ":&:" ++ show rest

and a homogenous case
newtype HoHeList (n :: Nat) a = HoHeList
    { unHoHeList :: HList (Replicate n a)
    }

now, i want to create a show-instance:
instance Show a => Show (HoHeList (n :: Nat) a) where
    show = (show . unHoHeList)

and prove it via (i am using your cong):
type TypeClassInduction a (n :: Nat) (f :: [Type] -> Type) (t :: Type -> Constraint)
    = t (f (Replicate n a))
$(genDefunSymbols [''TypeClassInduction])

typeClassInduction :: forall (n :: Nat) (a :: Type) (f :: [Type] -> Type) (t :: Type -> Constraint).
    (SingI n, t (f '[a]), forall xs x. (t (f xs), t x) => t (f (x ': xs)))
    => TypeClassInduction a n f t
typeClassInduction = elimNat @(TypeClassInduction a n f t) @n (sing @Nat @n) base step
        where
            base :: TypeClassInduction a 0 f t
            base = Refl

            step :: forall (k :: Nat).
                Sing k
                -> TypeClassInduction a k f t
                -> TypeClassInduction a (k :+ 1) f t
            step _ = case replicateSucc @k @a of
                        Refl -> cong @_ @_ @((:$$) (what should i pass here...i don't really understand :$$))

it seems like I could just use elimNat again, but I am not sure. I get these errors that I am not sure how to solve:
$(genDefunSymbols [''TypeClassInduction])

results in
Expected kind ‘* -> Constraint’, but ‘t0’ has kind ‘* -> *’

removing it results genDefunSymbols in
Expected a type, but
      ‘TypeClassInduction a n f t’ has kind
      ‘Constraint’

This is understandable since I am not returning a type, but instead a constraint. Is there a way to solve this?
(also, forall xs x. (t (f xs), t x) => t (f (x ': xs)) is not valid haskell...but it seemed natural to write)
Edit:
replicateSucc is defined as
axiom :: a :~: b
axiom = unsafeCoerce Refl

replicateSucc :: forall k a. Replicate (k :+ 1) a :~: (a : Replicate k a)
replicateSucc = axiom

Also, I have just played a bit around with your eliminators package a few months ago, but writing this was easy. I this would not be some constraint, but instead a normal type, I think I would have figured it out myself! 🙂

Urk.  In GHC Core, the Constraint and Type kinds are actually the same, which unfortunately means that there are certain places where GHC will confuse the two, such as Template Haskell reification. As a consequence, genDefunSymbols will produce ill-kinded types, since the information it reified was itself ill-kinded.
I'm afraid the only workaround for the time being is to just create the defunctionalization symbols by hand:
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeOperators #-}
module Foo where

import Data.Kind
import Data.Singletons
import Data.Singletons.Prelude.List
import GHC.TypeNats

type TypeClassInduction a (n :: Nat) (f :: [Type] -> Type) (t :: Type -> Constraint)
    = t (f (Replicate n a))
data TypeClassInductionSym0 :: k ~> Nat ~> ([Type] -> Type) ~> (Type -> Constraint) ~> Constraint
data TypeClassInductionSym1 :: k -> Nat ~> ([Type] -> Type) ~> (Type -> Constraint) ~> Constraint
data TypeClassInductionSym2 :: k -> Nat -> ([Type] -> Type) ~> (Type -> Constraint) ~> Constraint
data TypeClassInductionSym3 :: k -> Nat -> ([Type] -> Type) -> (Type -> Constraint) ~> Constraint
type instance Apply  TypeClassInductionSym0 a          = TypeClassInductionSym1 a
type instance Apply (TypeClassInductionSym1 a) n       = TypeClassInductionSym2 a n
type instance Apply (TypeClassInductionSym2 a  n) f    = TypeClassInductionSym3 a n f
type instance Apply (TypeClassInductionSym3 a  n  f) t = TypeClassInduction     a n f t

okay, thank you!
But I am still not sure how I can do a induction over some constraint.
I can't return TypeClassInduction a n f t....or can I?

I'm not sure either!
All of the code in this library is built around predicates p such that p :: <datatype> ~> Type. You're trying to use an exotic predicate of kind <datatype> ~> Constraint, which certainly won't kind-check with the eliminators in this library. Moreover, I don't how one would even write a hypothetical eliminator that would support such a predicate. It's certainly not something I've ever seen in any dependently typed languages—are there examples out there of folks doing this sort of thing?

I don't know either 😀 This was more out of need (all this hassle leads me trying to write a good old Show-Instance 😉).
I, unfortunately, have not much experience with "other" dependently typed languages, I have just played around with idris a bit and that's all.

In any case, you're barking up the wrong tree with typeClassInduction—it's not going to be well kinded either, as its return type is of kind Constraint, not Type, so it's not even a well formed function.
I suspect what you really want is something akin to a type-level eliminator.

Sadly, this is not possible in today's GHC, as its support for higher-ranked kinds in type families is extremely limited (see Trac #11719).

yeah, i knew that this is not a well-defined funktion, I hoped there there is something like :~:.
Hmm, so what can i do now? I don't think unsafeCoerce will work...

Hmm, so what can i do now?

Not much, I'm afraid. You're sailing through relatively uncharted waters on the fringes of GHC's type system, and you shouldn't be surprised if you hit impasses like this. There may be some other way to define your Show instance, but one thing is clear: eliminators aren't the solution (at present).

Thank you for your patience 🙂
It's not only uncharted, I am also (not yet?) that knowledgable what my options are and what's impossible.

I don't want to bother you, but...could a different formulation of eliminators maybe work when i try something like like this?
type CanShow a n = HList (Replicate n a) -> String
$(genDefunSymbols [''CanShow])

canShowInduction :: forall (n :: Nat) (a :: Type) y (as :: [Type]).
        (SingI n, Show a)
    => CanShow a n
canShowInduction = elimNat @(CanShowSym1 a) @n (sing @Nat @n) base step
    where
        base :: CanShow a 0
        base = show

        step :: forall (k :: Nat).
            Sing k
            -> CanShow a k
            -> CanShow a (k :+ 1)
        step _ _ = case replicateSucc @k @a of
                    Refl -> show

with a different formulation of step, so maybe something like this:
type ShowConstraint a n = Show (HList(Replicate n a))
type CanShow a n = HList (Replicate n a) -> String
$(genDefunSymbols [''CanShow])

canShowInduction :: forall (n :: Nat) (a :: Type) y.
        (SingI n, Show a)
    => CanShow a n
canShowInduction = elimNat @(CanShowSym1 a) @n (sing @Nat @n) base step
    where
        -- (how can i get the (ShowConstraint a 0) from here?)
        base :: CanShow a 0
        base = show

        step :: forall (k :: Nat). (ShowConstraint a k)
            Sing k
            -> CanShow a (k :+ 1)
        step _ = case replicateSucc @k @a of
                    Refl -> show

I don't know whether this would actually help or just move the problem into eliminators.
Also, I don't know whether GHC could figure it out, but I would guess so since show then exactly has the information it needs.
Another Problem here is that I can't replace it with an unsafeCoerce using some rule, actually running them was not my intention 😀.

I can't believe it...I've just solved it 😀 Eliminators is awesome!!
data Dict ctxt where
    Dict :: ctxt => Dict ctxt

type TypeClassInduction a (f :: [Type] -> Type) (t :: Type -> Constraint) (n :: Nat)
    = Dict (t (f (Replicate n a)))

-- due to https://ghc.haskell.org/trac/ghc/ticket/11715 we can't generate it
data TypeClassInductionSym0 :: k ~> ([Type] -> Type) ~> (Type -> Constraint) ~> Nat ~> Type
data TypeClassInductionSym1 :: k -> ([Type] -> Type) ~> (Type -> Constraint) ~> Nat ~> Type
data TypeClassInductionSym2 :: k -> ([Type] -> Type) -> (Type -> Constraint) ~> Nat ~> Type
data TypeClassInductionSym3 :: k -> ([Type] -> Type) -> (Type -> Constraint) -> Nat ~> Type
type instance Apply  TypeClassInductionSym0 a          = TypeClassInductionSym1 a
type instance Apply (TypeClassInductionSym1 a) f       = TypeClassInductionSym2 a f
type instance Apply (TypeClassInductionSym2 a  f) t    = TypeClassInductionSym3 a f t
type instance Apply (TypeClassInductionSym3 a  f  t) n = TypeClassInduction     a f t n

typeClassInduction :: forall (n :: Nat) (a :: Type) (f :: [Type] -> Type) (t :: Type -> Constraint).
    (SingI n, t (f '[]), (t a))
    => (forall xs x. Dict (t (f xs)) -> Dict (t x) -> Dict (t (f (x ': xs)))) -> TypeClassInduction a f t n
typeClassInduction cStep = elimNat @(TypeClassInductionSym3 a f t) @n (sing @Nat @n) base step
        where
            base :: TypeClassInduction a f t 0
            base = Dict @(t (f (Replicate 0 a)))

            step :: forall (k :: Nat).
                Sing k
                -> TypeClassInduction a f t k
                -> TypeClassInduction a f t (k :+ 1)
            step _ prev = case replicateSucc @k @a of
                        Refl -> (cStep prev (Dict @(t a)))

usage
newtype HoHeList (n :: Nat) a = HoHeList
    { unHoHeList :: HList (Replicate n a)
    }

instance (SingI n, Show a) => Show (HoHeList (n :: Nat) a) where
    show :: forall xs. xs ~ (Replicate n a) => HoHeList n a -> String
    show homogenous = let unhom :: HList xs = unHoHeList homogenous in
        case typeClassInduction @n @a @HList @Show constrStep of
            Dict -> show unhom
        where
            constrStep :: forall (a :: Type) (ts :: [Type]).
                Dict (Show (HList ts)) -> Dict (Show a) -> Dict (Show (HList (a : ts)))
            constrStep Dict Dict = Dict

ghci
*V2.HList> vals = 1 :&: 2 :&: 3 :&: HNil
*V2.HList> proveHomogenous vals
1:&:2:&:3:&:[]
*V2.HList> :t proveHomogenous vals
proveHomogenous vals :: Num t1 => HoHeList 3 t1
*V2.HList> hohe = proveHomogenous vals
*V2.HList> show hohe
"1:&:2:&:3:&:[]"

While I'm glad you found a solution, it now occurs to me that this is all completely overkill for the problem you're trying to solve. The root of the issue is that you have these two Show instances for HList:
instance (Show (HList '[])) where
    show _ = "[]"

instance (Show a, Show (HList ts)) => (Show (HList (a : ts))) where
    show (a :&: rest) = show a ++ ":&:" ++ show rest

These will only ever apply if you know statically that an HList is empty or headed by (:). But that's not the case in your Show instance for HoHeList, which is why you were struggling to define it.
If I may, I'd like to propose a much simpler solution that doesn't use eliminators at all:
{-# LANGUAGE GADTs #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE UndecidableInstances #-}
module Foo where

import Data.Kind
import Data.Singletons.Prelude.List
import GHC.TypeNats

data HList (ts :: [Type]) where
    HNil :: HList '[]
    (:&:) :: t -> HList ts -> HList (t ': ts)

infixr 5 :&:

type family AllC (f :: Type -> Constraint) (xs :: [Type]) :: Constraint where
  AllC _ '[]    = ()
  AllC f (x:xs) = (f x, AllC f xs)

deriving instance AllC Show xs => Show (HList xs)

newtype HoHeList (n :: Nat) a = HoHeList
    { unHoHeList :: HList (Replicate n a)
    }

deriving instance AllC Show (Replicate n a) => Show (HoHeList n a)

The key here is in the use of AllC. With this, you can define a single Show instance for all HLists, which makes defining a Show instance for HoHeList trivial. (You'll have to enable UndecidableInstances for this trick to work, but whatever.)
Now maybe some day we can define AllC by means of a type-level eliminator, but for the time being, you'll have to do the dirty work of defining it by direct recursion.

Do you know what actually happens when I run typeClassInduction? The types all make sense...but I don't know whether the code actually does something.

It certainly does something: it computes a Dict—linearly in the size of n, I might add. In other dependently typed languages, this might take constant time, since you could have an eta rule that says that all terms of type Dict reduce to the Dict constructor, but GHC does not have this ability due to its lazy evaluation order.

Well, at least I learned something!
Here's something interesting: At least in GHCi, printing a HoHeList 2000 Nat-List using my eliminator-based formulation is not noticeably slower than printing a replicate 2000 1-list. But the normal Show, without your formulation, is super slow (it nearly crashes for me on a 2000 vector and consumes A LOT of memory (gigabytes!). It seems that the memory does grow exponential or at least has a big coefficient in front of it).
If I am not building the type-level list and instead use:
replicateH2 :: SNat n -> a -> HoHeList n a
replicateH2 n a =
    HoHeList (unsafeCoerce (iterate (unsafeCoerce . (a :&:)) HNil
                !! fromInteger (fromSing n)))

and then show it, I don't notice any (!!) slowdown between this formulation and not using not a type-level list. I can print homMany = replicateH2 (sing @Nat @200000) 1.
I have not tested your approach yet and I don't have time until tomorrow, but I bet it would require building the actual type-level list.

Am I abusing the github ticket-system in your view? Is this even interesting to you?

I don't think this is abusing GitHub at all! This stuff is far from obvious (both from a GHC programmer's perspective, and from the perspective of someone accustomed to dependent types in other languages).
I can't say I'm surprised to learn that code using elimNat is inefficient—you're likely seeing the combined effect of inefficient Natural code plus a complete lack of fusion that you're likely accustomed to for most data types, like lists. This library was intended to be a proof of concept, after all, and not a blazing-fast reference implementation! :)
If you're convinced that your proofs are correct, you can always make a rewrite RULE to zap it away at runtime:
{-# RULES "typeClassInductionTerminates" typeClassInduction x = unsafeCoerce Dict #-}

I can't guarantee that's the only bottleneck in your code, but it would at least obviate an obvious culprit.

I think you misunderstood me (or I wasn't very clear)!
At least I was surprised how efficient elimNat is. This is working:
> homMany = replicateH2 (sing @Nat @200000) 1
> homMany
(just prints a lot of 1s)
> (+1) <$> homMany
(just prints a lot of 2s)
> foldr (+) 0 homMany
20000

where
replicateH2 :: SNat n -> a -> HoHeList n a
replicateH2 n a =
    HoHeList (unsafeCoerce (iterate (unsafeCoerce . (a :&:)) HNil
                !! fromInteger (fromSing n)))

to avoid actually building the type-level list. Having a type-level list of more than 2000 Elements eats all my RAM (so actually evaluating Replicate 2000 Nat)
I don't notice any slowdown compared to the just calling replicate without type level stuff when using large lists.


Favorite Issues and PRs

Add a new tab and the option to favorite/star Issues/PRs so you can quickly nav back to them later.

This covered by the Bookmarks work?

Think so huh!


use more fastboot friendly liquid fire

@ef4 can you merge this PR and rev? this add-on doesn't use the fastboot friendly version of liquid fire that we worked on, and is preventing our app from playing nice in fastboot.

Published as 1.0.0.


Tagging scheme broken

Hi! I would like to package pynitrokey for Arch Linux.
Unfortunately the tagging scheme is now broken with using v0.4 instead of v0.4.nitrokey, as there are upstream solo-python related tags and nitrokey related tags in use in this repository and I am using a regular expression match against the nitrokey specific suffix.
Will tags from now on not have the suffixes anymore?
If not, please tag v0.4 also as v4.0.nitrokey.
Thanks!

Hi! Thank you for noticing that!
Indeed, I think it should be 0.4.0.nitrokey, so we would not conflict with upstream's tags. Same scheme is used with Nitrokey FIDO2. What's your view @daringer?

oops, yeah brings us to the whole "not being a fork anymore topic" ... but that's a second topic, will release a v0.4.1.nitrokey with some recent fixes (including #43) today. Then asap bring the fork topic to a higher prio...

Released 0.4.1 using tag: v0.4.1.nitrokey

https://www.archlinux.org/packages/community/any/python-pynitrokey/


Python Version of Black Litterman PCM Throws ValueError

Expected Behavior

The python implementation of BlackLittermanOptimizationPortfolioConstructionModel matches the C# implementation.
Actual Behavior

The python implementation of BlackLittermanOptimizationPortfolioConstructionModel doesn't match the C# implementation. For instance, this backtest shows that when a security in symbolDataBySymbol doesn't have an active insight, the matrix multiplication in apply_blacklitterman_master_formula fails.
Potential Solution

N/A
Reproducing the Problem

See the backtest above.
System Information

QC Cloud
Checklist

[x] I have completely filled out this template
[x] I have confirmed that this issue exists on the current master branch
[x] I have confirmed that this is not a duplicate issue by searching issues

[x] I have provided detailed steps to reproduce the issue

I hacked something together in my fork. Unfortunately all we gain is sometimes backtesting works, and sometimes we just get Value Errors moved the ROC function in the SymbolData class.


name compression is slow

This is due to the same flamegraphs that show #13.
Name compression as it currently stands uses a lot of cpu time, and it's all at lookup time (i.e. inside getSuffix) rather than mutate time, which is how a suffix trie is supposed to work.
An easy change would be just to replace the half-hearted trie with a plain Map of all the suffixes and use that instead.

After cleaning up the Map in the NameOffsetCache, it becomes painfully obvious that the string splitting/joining going on is a big part of the slowdown, too, and it's all wrapped up in this so we should change it to use indexes and indexOf instead.


Rasa's install of old Tensorflow breaks "curl"

Rasa 1.6.1
Python version:
3.7.6.
Operating system (windows, osx, ...):
Ubuntu 18.04 LTS
Issue:
Rasa's install of old Tensorflow breaks "curl", which breaks iDrive backups
Installing current Rasa installs obsolete Tensorflow 1.15. Tensorflow installs its own modded version of libcurl, turning on Google Cloud support. This messes up dependencies and means "curl", the command line program, cannot be installed. This, in turn, breaks the iDrive backup system because "curl" is missing.
This is mostly a Tensorflow problem, but because it's a Tensorflow problem in an older version, it's unlikely to be fixed from a bug report on Tensorflow.
More details here, in Ubuntu forums.
Ref: https://ubuntuforums.org/showthread.php?t=2435412
Error (including full traceback):

Command or request that led to error:

Content of configuration file (config.yml) (if relevant):

Content of domain file (domain.yml) (if relevant):

we are working on upgrading to TF 2.0 #5127 #5087
This will be closed as soon as that is released. until then I don't think there is anything we can do.


[Bug Report]: Base table bookstack.webhooks doesn't exist

Describe the Bug
When i try to go to webhook settings i get an error
An unknown error occurred
Steps to Reproduce

Go to settings
Webhooks
error

Expected Behaviour
Illuminate\Database\QueryException SQLSTATE[42S02]: Base table or view not found: 1146 Table 'bookstack.webhooks' doesn't exist (SQL: select * from webhooks order by name desc)
Screenshots or Additional Context
No response
Exact BookStack Version
v21.12.2
PHP Version
7.4.3
Hosting Environment
Ubuntu 20.04 VPS

Hi @unpokitodxfavor,
When you run the php artisan migrate step of the update commands do you get any errors? Did you see any errors on last update?

I have upgraded to BookStack v21.12.3 and now I can add webhooks.
Fixed

Upgrading laravel/ui (v3.3.2 => v3.4.1): Extracting archive
Upgrading aws/aws-sdk-php (3.202.2 => 3.209.11): Extracting archive
Upgrading league/oauth2-client (2.6.0 => 2.6.1): Extracting archive
Upgrading paragonie/constant_time_encoding (v2.4.0 => v2.5.0): Extracting archive
Upgrading phpseclib/phpseclib (3.0.11 => 3.0.12): Extracting archive
Upgrading predis/predis (v1.1.9 => v1.1.10): Extracting archive
Upgrading socialiteproviders/manager (4.0.1 => v4.1.0): Extracting archive
Upgrading ssddanbrown/htmldiff (v1.0.1 => v1.0.2): Extracting archive
Package swiftmailer/swiftmailer is abandoned, you should avoid using it. Use symfony/mailer instead.
Generating optimized autoload files

Illuminate\Foundation\ComposerScripts::postAutoloadDump
@php artisan package:discover --ansi
In StreamHandler.php line 146:

The stream or file "/var/www/bookstack/storage/logs/laravel.log" could not be opened in append mode: failed to
open stream: Permission denied
57 packages you are using are looking for funding.
Use the composer fund command to find out more!

@php artisan cache:clear
Failed to clear cache. Make sure you have the appropriate permissions.
@php artisan view:clear
Compiled views cleared!

Application In Production!     *

Do you really wish to run this command? (yes/no) [no]:

yes
Migrating: 2021_11_26_070438_add_index_for_user_ip
Migrated:  2021_11_26_070438_add_index_for_user_ip (59.86ms)
Migrating: 2021_12_07_111343_create_webhooks_table
Migrated:  2021_12_07_111343_create_webhooks_table (152.55ms)
Migrating: 2021_12_13_152024_create_jobs_table
Migrated:  2021_12_13_152024_create_jobs_table (59.76ms)
Migrating: 2021_12_13_152120_create_failed_jobs_table
Migrated:  2021_12_13_152120_create_failed_jobs_table (47.00ms)
Migrating: 2022_01_03_154041_add_webhooks_timeout_error_columns
Migrated:  2022_01_03_154041_add_webhooks_timeout_error_columns (23.19ms)


Enable prometheus flags for system processes in helm charts

Description

Enable prometheus flags for system processes in helm
Bump chart versions to 0.2.2

Issue reference
#1198
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation
[ ] Specification has been updated
[ ] Provided sample for the feature

LGTM

LGTM

waiting for the review of this pr - https://github.com/dapr/dapr/pull/1198

/ok-to-test


API complains on resources exist during helm install and which actually not

Environmental Info:
K3s Version:
k3s version v1.27.5+k3s1 (8d074ecb)
go version go1.20.7
Node(s) CPU architecture, OS, and Version:
uname -a
Linux 8BMQ363 5.3.18-150300.59.118-default https://github.com/k3s-io/k3s/issues/1 SMP Tue Apr 4 15:18:05 UTC 2023 (d9b953c) x86_64 x86_64 x86_64 GNU/Linux
Cluster Configuration:
single node with postgresql as etcd db
Postgresql Config:
~/yang-provider # cat /var/lib/pgsql/data/postgresql.conf
listen_addresses = '<IP_ADDRESS>'		# what IP address(es) to listen on;
max_connections = 200
k3s-server config:
~/yang-provider # cat /etc/rancher/k3s/k3s-server.env
K3S_SERVER_ARGS="--disable coredns,servicelb,traefik,local-storage,metrics-server
--flannel-backend=none
--datastore-endpoint='postgres://k3s:k3s@<IP_ADDRESS>:5432/k3s?sslmode=disable'
--pause-image=docker-registry.docker-registry.svc.cluster.local:5000/rancher/mirrored-pause:3.6
--bind-address <IP_ADDRESS>
--node-ip=<IP_ADDRESS>
--service-cidr <IP_ADDRESS>/24
--cluster-dns <IP_ADDRESS>
--cluster-cidr=<IP_ADDRESS>/24
--disable-network-policy
--kube-controller-manager-arg node-cidr-mask-size=24
--kubelet-arg config=/var/lib/rancher/k3s/server/kubelet.yaml
--kube-apiserver-arg feature-gates=ServiceIPStaticSubrange=true
--kube-apiserver-arg='audit-log-path=/var/log/k3s/audit/audit.log'
--kube-apiserver-arg='audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml'
--debug
-v=9
--log=/var/log/k3s/k3s.log
--kube-apiserver-arg event-ttl=4h"
Describe the bug:
during helm installation kube-api complains resources exist, but while checking cluster information, the resources were not there.
Steps To Reproduce:
run this simply one line script with given chart in https://github.com/tibetsam/yang-provider
~/yang-provider # for i in $(seq 1 20); do printf "\nINSTALLING, $i ITERATION\n"; helm install yang -n pc ./ ; kubectl get configmap yang-provider-confd-config -n pc; echo "sleeping 5s"; sleep 5;  echo "DELETING"; helm delete yang -n pc; done
INSTALLING, 1 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 13:59:52 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      0s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 2 ITERATION
Error: INSTALLATION FAILED: configmaps "yang-provider-confd-config" already exists
Error from server (NotFound): configmaps "yang-provider-confd-config" not found
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 3 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:00:07 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      0s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 4 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:00:15 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      1s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 5 ITERATION
Error: INSTALLATION FAILED: configmaps "yang-provider-confd-config" already exists
Error from server (NotFound): configmaps "yang-provider-confd-config" not found
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 6 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:00:30 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      1s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 7 ITERATION
Error: INSTALLATION FAILED: configmaps "yang-provider-confd-config" already exists
Error from server (NotFound): configmaps "yang-provider-confd-config" not found
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 8 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:00:44 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      0s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 9 ITERATION
Error: INSTALLATION FAILED: configmaps "yang-provider-confd-config" already exists
Error from server (NotFound): configmaps "yang-provider-confd-config" not found
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 10 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:00:59 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      0s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 11 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:01:08 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      1s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 12 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:01:17 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      1s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 13 ITERATION
Error: INSTALLATION FAILED: configmaps "yang-provider-confd-config" already exists
Error from server (NotFound): configmaps "yang-provider-confd-config" not found
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 14 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:01:34 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      0s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 15 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:01:42 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      1s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 16 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:01:49 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      0s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 17 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:01:57 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      1s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 18 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:02:04 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      0s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 19 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:02:11 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      1s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 20 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 14:02:19 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      0s
sleeping 5s
DELETING
release "yang" uninstalled
Expected behavior:
helm install should succeed no matter how many times install/uninstall
Actual behavior:
helm install failing time to time
Additional context / logs:

additional logs from postgres and audit.log shows that although db receives insert command, but looks like data isn't saved correctly in DB, bcz looking at the pattern in postgres log and timestamp in audit.log, we can see that whenever api fails, the following db insert command uses same prev_revision.
postgres.log
2023-10-20 15:01:33.852 UTC k3s k3s [13963]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:01:34.021 UTC k3s k3s [13963]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:01:34.022 UTC k3s k3s [13963]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '0', $6 = '0', $7 = '
2023-10-20 15:01:34.408 UTC k3s k3s [13963]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:01:40.212 UTC k3s k3s [13963]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:01:40.215 UTC k3s k3s [13963]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:01:40.217 UTC k3s k3s [13963]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '0', $3 = '1', $4 = '1318860', $5 = '1318860', $6 = '0', $7 = '
2023-10-20 15:01:41.290 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:01:41.468 UTC k3s k3s [13963]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:01:41.471 UTC k3s k3s [13963]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1318883', $6 = '0', $7 = '
2023-10-20 15:01:41.839 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:01:47.654 UTC k3s k3s [15886]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:01:47.658 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:01:47.660 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '0', $3 = '1', $4 = '1318898', $5 = '1318898', $6 = '0', $7 = '
2023-10-20 15:01:48.712 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:01:48.903 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:01:48.906 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1318924', $6 = '0', $7 = '
2023-10-20 15:01:49.278 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:01:55.116 UTC k3s k3s [16184]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:01:55.121 UTC k3s k3s [16184]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:01:55.124 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '0', $3 = '1', $4 = '1318939', $5 = '1318939', $6 = '0', $7 = '
2023-10-20 15:01:56.201 UTC k3s k3s [15886]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:01:56.389 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:01:56.391 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1318963', $6 = '0', $7 = '
2023-10-20 15:01:56.746 UTC k3s k3s [13965]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:02.545 UTC k3s k3s [15886]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:02.554 UTC k3s k3s [15886]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:02:02.556 UTC k3s k3s [15886]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '0', $3 = '1', $4 = '1318979', $5 = '1318979', $6 = '0', $7 = '
2023-10-20 15:02:03.629 UTC k3s k3s [16586]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:03.808 UTC k3s k3s [16586]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:02:03.811 UTC k3s k3s [16586]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1319002', $6 = '0', $7 = '
2023-10-20 15:02:04.175 UTC k3s k3s [15886]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:10.017 UTC k3s k3s [16923]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:10.034 UTC k3s k3s [16924]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:02:10.037 UTC k3s k3s [15886]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '0', $3 = '1', $4 = '1319018', $5 = '1319018', $6 = '0', $7 = '
2023-10-20 15:02:11.103 UTC k3s k3s [16586]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:11.311 UTC k3s k3s [15886]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:02:11.314 UTC k3s k3s [15886]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1319044', $6 = '0', $7 = '
2023-10-20 15:02:11.329 UTC k3s k3s [16979]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:11.699 UTC k3s k3s [16978]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:17.520 UTC k3s k3s [17216]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:18.580 UTC k3s k3s [16978]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:18.760 UTC k3s k3s [16979]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:02:18.763 UTC k3s k3s [16979]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1319044', $6 = '0', $7 = '
2023-10-20 15:02:19.128 UTC k3s k3s [16979]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:24.950 UTC k3s k3s [17541]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:24.955 UTC k3s k3s [17541]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:02:24.958 UTC k3s k3s [16978]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '0', $3 = '1', $4 = '1319098', $5 = '1319098', $6 = '0', $7 = '
2023-10-20 15:02:26.037 UTC k3s k3s [17542]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:26.229 UTC k3s k3s [16979]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:02:26.232 UTC k3s k3s [16979]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1319122', $6 = '0', $7 = '
2023-10-20 15:02:26.246 UTC k3s k3s [16979]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:26.599 UTC k3s k3s [17542]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:32.442 UTC k3s k3s [17863]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:33.499 UTC k3s k3s [17863]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:33.695 UTC k3s k3s [17863]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:02:33.697 UTC k3s k3s [17863]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1319122', $6 = '0', $7 = '
2023-10-20 15:02:33.994 UTC k3s k3s [17863]DETAIL:  parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
audit log:
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"b1df0f5a-9f0b-46b5-a1a1-65970f5429e0","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/pc/configmaps?fieldManager=helm","verb":"create","user":{"username":"system:admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["<IP_ADDRESS>"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"configmaps","namespace":"pc","name":"yang-provider-confd-config","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":201},"requestReceivedTimestamp":"2023-10-20T15:01:34.012171Z","stageTimestamp":"2023-10-20T15:01:34.033374Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"130cc136-2b88-448b-a96f-9c3af56a1a1e","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/pc/configmaps?fieldManager=helm","verb":"create","user":{"username":"system:admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["<IP_ADDRESS>"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"configmaps","namespace":"pc","name":"yang-provider-confd-config","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":201},"requestReceivedTimestamp":"2023-10-20T15:01:41.460761Z","stageTimestamp":"2023-10-20T15:01:41.489885Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"5745943d-1334-4cfc-8793-761335452211","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/pc/configmaps?fieldManager=helm","verb":"create","user":{"username":"system:admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["<IP_ADDRESS>"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"configmaps","namespace":"pc","name":"yang-provider-confd-config","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":201},"requestReceivedTimestamp":"2023-10-20T15:01:48.889951Z","stageTimestamp":"2023-10-20T15:01:48.920542Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"d6bf8b08-c5dd-4ea3-b3a9-15c7acb192c7","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/pc/configmaps?fieldManager=helm","verb":"create","user":{"username":"system:admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["<IP_ADDRESS>"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"configmaps","namespace":"pc","name":"yang-provider-confd-config","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":201},"requestReceivedTimestamp":"2023-10-20T15:01:56.376602Z","stageTimestamp":"2023-10-20T15:01:56.407530Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"390a3ae1-3d50-45bc-88d1-4c3ee808e756","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/pc/configmaps?fieldManager=helm","verb":"create","user":{"username":"system:admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["<IP_ADDRESS>"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"configmaps","namespace":"pc","name":"yang-provider-confd-config","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":201},"requestReceivedTimestamp":"2023-10-20T15:02:03.795302Z","stageTimestamp":"2023-10-20T15:02:03.827643Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"b4e3b4ba-2223-4b0b-a94f-25b1eaa1b4c8","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/pc/configmaps?fieldManager=helm","verb":"create","user":{"username":"system:admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["<IP_ADDRESS>"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"configmaps","namespace":"pc","name":"yang-provider-confd-config","apiVersion":"v1"},"responseStatus":{"metadata":{},"status":"Failure","message":"configmaps "yang-provider-confd-config" already exists","reason":"AlreadyExists","details":{"name":"yang-provider-confd-config","kind":"configmaps"},"code":409},"requestReceivedTimestamp":"2023-10-20T15:02:11.300403Z","stageTimestamp":"2023-10-20T15:02:11.330231Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"62311d36-b48d-46a5-a79b-e1bd03e7103f","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/pc/configmaps?fieldManager=helm","verb":"create","user":{"username":"system:admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["<IP_ADDRESS>"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"configmaps","namespace":"pc","name":"yang-provider-confd-config","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":201},"requestReceivedTimestamp":"2023-10-20T15:02:18.746873Z","stageTimestamp":"2023-10-20T15:02:18.778152Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"9ce9f005-3e39-4e91-a254-aaff9296ed66","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/pc/configmaps?fieldManager=helm","verb":"create","user":{"username":"system:admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["<IP_ADDRESS>"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"configmaps","namespace":"pc","name":"yang-provider-confd-config","apiVersion":"v1"},"responseStatus":{"metadata":{},"status":"Failure","message":"configmaps "yang-provider-confd-config" already exists","reason":"AlreadyExists","details":{"name":"yang-provider-confd-config","kind":"configmaps"},"code":409},"requestReceivedTimestamp":"2023-10-20T15:02:26.216425Z","stageTimestamp":"2023-10-20T15:02:26.247106Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"2f3d09c8-7abc-4146-8ab2-5595b85c56d4","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/pc/configmaps?fieldManager=helm","verb":"create","user":{"username":"system:admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["<IP_ADDRESS>"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"configmaps","namespace":"pc","name":"yang-provider-confd-config","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":201},"requestReceivedTimestamp":"2023-10-20T15:02:33.681942Z","stageTimestamp":"2023-10-20T15:02:33.712285Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}

~/yang-provider # for i in $(seq 1 20); do printf "\nINSTALLING, $i ITERATION\n"; helm install yang -n pc ./ ; kubectl get configmap yang-provider-confd-config -n pc; echo "sleeping 5s"; sleep 5; echo "DELETING"; helm delete yang -n pc; done

Don't do that.
Kubernetes has an eventual consistency model. When you delete a resource, it isn't actually deleted immediately. It just sets a deletion timestamp on the object, and any controllers that have a finalizer on the object are given a chance to see that it has been marked for deletion. Once all controllers remove themselves from the finalizer list on the object, it is actually deleted by the garbage collector. Even with no finalizers, it may be a moment before the object is actually deleted.
If you want your Helm chart to actually wait for all the objects to be deleted before you try to reinstall, you should use the --wait flag on your helm delete command. If you don't do this, helm will start installing again while the objects are still in the process of being deleted by the apiserver. Helm will see that they exist initially, and try to update them, but then by the time it gets to updating them, the deletion has completed and it gets a "not found" error.
Ideally you would also use the --wait flag on your install command, to wait for your workload to roll out successfully before you try to uninstall it again.

@brandond thanks for the tip. I think my problem is not bcz couldn't delete resources cleanly. I can even reproduce this issue on a fresh cluster. And from postgres logs we can see both insert with create and delete from api server.
Anyway, i will repeat the test with --wait command and get back you soon. Thanks again

FYI, the issue exist with --wait command
~/yang-provider # for i in $(seq 1 20); do printf "\nINSTALLING, $i ITERATION\n"; helm install yang -n pc ./ --wait ; kubectl get configmap yang-provider-confd-config -n pc; echo "sleeping 5s"; sleep 5;  echo "DELETING"; helm delete yang -n pc --wait; done
INSTALLING, 1 ITERATION
Error: INSTALLATION FAILED: cannot re-use a name that is still in use
NAME                         DATA   AGE
yang-provider-confd-config   2      165m
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 2 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 17:48:30 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      1s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 3 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 17:48:38 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      0s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 4 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 17:48:46 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      1s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 5 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 17:48:53 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      0s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 6 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 17:49:01 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      1s
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 7 ITERATION
Error: INSTALLATION FAILED: configmaps "yang-provider-confd-config" already exists
Error from server (NotFound): configmaps "yang-provider-confd-config" not found
sleeping 5s
DELETING
release "yang" uninstalled
INSTALLING, 8 ITERATION
NAME: yang
LAST DEPLOYED: Fri Oct 20 17:49:16 2023
NAMESPACE: pc
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Service is deployed as yang-provider
NAME                         DATA   AGE
yang-provider-confd-config   2      1s

please note , the issue is not "not found", it is "already exist". :D

Error: INSTALLATION FAILED: configmaps "yang-provider-confd-config" already exists
Error from server (NotFound): configmaps "yang-provider-confd-config" not found

It looks to me like it still exists from the previous run, and then a moment later is gone. Postgres is one of the lower performance backends for kine for whatever reason, so I wouldn't be surprised if issues like this are easier to reproduce when using it.
I'll see if this can be reproduced without helm, but it really looks to me like a race condition in helm and not an issue with the apiserver.

It looks to me like it still exists from the previous run, and then a moment later is gone

but then it can't explain why this can happen on a fresh cluster, and here fresh means complete new VM and new k3s cluster.

I'll see if this can be reproduced without helm, but it really looks to me like a race condition in helm and not an issue with the apiserver or kine.

thanks, what i can also try is to put more delay in between and delete namespace and check resources before installing helm

@brandond I have reproduced this issue with a modified version of the loadmap.py testscript from kine.
Currently testing with k3s-1.27.1+k3s1, but have earlier verified the issue exists on k3s-1.27.6+k3s1 as well.
Usually 10-50 creations out of 1000 fails with this script. Please let me know if you want any log files or other bits.
loadmap.py.gz

Postgres is one of the lower performance backends for kine for whatever reason

@brandond could you please elaborate a little bit more on this one?

Usually 10-50 creations out of 1000 fails with this script

What version of postgres are you using, and in what sort of configuration?

could you please elaborate a little bit more on this one?

We run a full test suite against all the supported backends on every PR and merge to Kine; you can find the perf figures in there. I'm not sure why postgres is slower than some other engines, but it is.

Oh, I see what you're doing. You modified the script to sequentially create configmaps, while deleting the configmap created 5 iterations prior. Sometimes when creating the configmap, an error is returned indicating that the configmap that you expected to have been previously deleted, still exists.
A few interesting notes:

If you try to get the configmap that the apiserver claims exists, it will return a Not Found error, following which the create can be retried and will succeed.
Reducing the size of the configmap data seems to make this hard or impossible to reproduce.
Watching configmap events does not appear to show any deletes being skipped:
kubectl get configmap -A --watch-only --output-watch-events
After several runs I see slow SQL warnings from k3s, and if I keep at it long enough it will eventually start complaining about compaction failing due to the compact transaction timing out and rolling back:INFO[0608] Slow SQL (started: 2023-10-25 00:19:12.901593252 +0000 UTC m=+602.473386863) (total time: 6.388648089s):  DELETE FROM kine AS kv USING ( SELECT kp.prev_revision AS id FROM kine AS kp WHERE kp.name != 'compact_rev_key' AND kp.prev_revision != 0 AND kp.id <= $1 UNION SELECT kd.id AS id FROM kine AS kd WHERE kd.deleted != 0 AND kd.id <= $2 ) AS ks WHERE kv.id = ks.id : [[3002 3002]]
ERRO[0608] Compact failed: failed to record compact revision: sql: transaction has already been committed or rolled back

This feels to me like a slow datastore causing a cache somewhere in the apiserver to go stale, but it's hard to say where. This sounds very similar to an issue we've been tracking internally with watch events being missed in Kubernetes 1.27 and 1.28. We don't have an issue in GH yet but some basic logs from reproduction are available at https://gist.github.com/brandond/dd349d65d5afaf2e084e3d173d6c311e
Another possibility is that kine is affected by the GRPC watch stream starvation issue mentioned in https://github.com/k3s-io/k3s/issues/8415; I haven't had a chance to test to see whether or not removing the http mux from the kine listener makes any difference.

Just out of curiosity I tried v1.23.6+k3s1 which was the last release that did not include https://github.com/k3s-io/kine/pull/78, and it behaves the same... so that confirms that this is at least 1) not new behavior and 2) not made worse by that change.

I'm going to tinker with changing the grpc mux, and fixing https://github.com/k3s-io/kine/issues/215, and I'll see if I get any different behavior out of it.

OK, so I ran kine standalone with trace logging enabled and confirmed that the error is coming from postgres, NOT anything in the Kubernetes layer.
time="2023-10-25T16:43:11Z" level=trace msg="QUERY [/registry/configmaps/load-test/test-051 true] :  SELECT * FROM ( SELECT ( SELECT MAX(rkv.id) AS id FROM kine AS rkv), ( SELECT MAX(crkv.prev_revision) AS prev_revision FROM kine AS crkv WHERE crkv.name = 'compact_rev_key'), kv.id AS theid, kv.name, kv.created, kv.deleted, kv.create_revision, kv.prev_revision, kv.lease, kv.value, kv.old_value FROM kine AS kv JOIN ( SELECT MAX(mkv.id) AS id FROM kine AS mkv WHERE mkv.name LIKE $1 GROUP BY mkv.name) AS maxkv ON maxkv.id = kv.id WHERE kv.deleted = 0 OR $2 ) AS lkv ORDER BY lkv.theid ASC LIMIT 1"
time="2023-10-25T16:43:11Z" level=trace msg="QUERY ROW [/registry/configmaps/load-test/test-051 1 0 0 584 0 [...] [...]]  [...]] : INSERT INTO kine(name, created, deleted, create_revision, prev_revision, lease, value, old_value) values($1, $2, $3, $4, $5, $6, $7, $8) RETURNING id"
time="2023-10-25T16:43:11Z" level=trace msg="DELETE /registry/configmaps/load-test/test-051, rev=787 => rev=798, kv=true, deleted=true, err=<nil>"
time="2023-10-25T16:43:11Z" level=trace msg="TRIGGERED /registry/configmaps/load-test/test-051, revision=798, delete=true"
time="2023-10-25T16:43:11Z" level=trace msg="WATCH READ id=11, key=/registry/configmaps/load-test/test-051, revision=798"

time="2023-10-25T16:43:24Z" level=trace msg="QUERY [/registry/configmaps/load-test/test-051 true] :  SELECT * FROM ( SELECT ( SELECT MAX(rkv.id) AS id FROM kine AS rkv), ( SELECT MAX(crkv.prev_revision) AS prev_revision FROM kine AS crkv WHERE crkv.name = 'compact_rev_key'), kv.id AS theid, kv.name, kv.created, kv.deleted, kv.create_revision, kv.prev_revision, kv.lease, kv.value, kv.old_value FROM kine AS kv JOIN ( SELECT MAX(mkv.id) AS id FROM kine AS mkv WHERE mkv.name LIKE $1 GROUP BY mkv.name) AS maxkv ON maxkv.id = kv.id WHERE kv.deleted = 0 OR $2 ) AS lkv ORDER BY lkv.theid ASC LIMIT 1"
time="2023-10-25T16:43:24Z" level=trace msg="QUERY ROW [/registry/configmaps/load-test/test-051 1 0 0 798 0 [...] [...]]  [...]] : INSERT INTO kine(name, created, deleted, create_revision, prev_revision, lease, value, old_value) values($1, $2, $3, $4, $5, $6, $7, $8) RETURNING id"
time="2023-10-25T16:43:24Z" level=trace msg="CREATE /registry/configmaps/load-test/test-051, size=131290, lease=0 => rev=1008, err=<nil>"
time="2023-10-25T16:43:24Z" level=trace msg="TRIGGERED /registry/configmaps/load-test/test-051, revision=1008, delete=false"
time="2023-10-25T16:43:24Z" level=trace msg="WATCH READ id=11, key=/registry/configmaps/load-test/test-051, revision=1008"

We can see that kine is running the EXACT SAME query to create the row both times, but the first time postgres claims there's a "duplicate key". I first suspected that the duplicate key in question was for the name,prev_revision index but we know this can't be true because the same query succeeds the second time.
If we look at what's going on around this timeframe, we see kine complaining that the auto-increment primary key jumped forward at the exact same time we were trying to insert the row; kine responds by creating a "gap" record to ensure strict sequencing of event records.
time="2023-10-25T16:43:24Z" level=trace msg="QUERY [/registry/configmaps/load-test/test-045 true] :  SELECT * FROM ( SELECT ( SELECT MAX(rkv.id) AS id FROM kine AS rkv), ( SELECT MAX(crkv.prev_revision) AS prev_revision FROM kine AS crkv WHERE crkv.name = 'compact_rev_key'), kv.id AS theid, kv.name, kv.created, kv.deleted, kv.create_revision, kv.prev_revision, kv.lease, kv.value, kv.old_value FROM kine AS kv JOIN ( SELECT MAX(mkv.id) AS id FROM kine AS mkv WHERE mkv.name LIKE $1 GROUP BY mkv.name) AS maxkv ON maxkv.id = kv.id WHERE kv.deleted = 0 OR $2 ) AS lkv ORDER BY lkv.theid ASC LIMIT 1"
time="2023-10-25T16:43:24Z" level=trace msg="QUERY ROW [/registry/configmaps/load-test/test-045 0 1 990 990 0 [...] [...]]  [...]] : INSERT INTO kine(name, created, deleted, create_revision, prev_revision, lease, value, old_value) values($1, $2, $3, $4, $5, $6, $7, $8) RETURNING id"
time="2023-10-25T16:43:24Z" level=trace msg="QUERY [/registry/leases/kube-system/apiserver-lh46kuthsmhbsnvcyhx7sfkusm false] :  SELECT * FROM ( SELECT ( SELECT MAX(rkv.id) AS id FROM kine AS rkv), ( SELECT MAX(crkv.prev_revision) AS prev_revision FROM kine AS crkv WHERE crkv.name = 'compact_rev_key'), kv.id AS theid, kv.name, kv.created, kv.deleted, kv.create_revision, kv.prev_revision, kv.lease, kv.value, kv.old_value FROM kine AS kv JOIN ( SELECT MAX(mkv.id) AS id FROM kine AS mkv WHERE mkv.name LIKE $1 GROUP BY mkv.name) AS maxkv ON maxkv.id = kv.id WHERE kv.deleted = 0 OR $2 ) AS lkv ORDER BY lkv.theid ASC LIMIT 1"
time="2023-10-25T16:43:24Z" level=trace msg="QUERY ROW [/registry/leases/kube-system/apiserver-lh46kuthsmhbsnvcyhx7sfkusm 0 0 37 849 0 [...] [...]]
Because the lease update insert finished first, kine saw the id jump forward, and created a gap-fill record with id=1006 to fill what it thought was a skipped auto-increment row id. Creation of this gap-fill record also completed while creation of /registry/configmaps/load-test/test-051 was still in progress.
When the creation of /registry/configmaps/load-test/test-051 finally finished processing within postgres, id=1006 that postgres had been planning to use for that row was now taken by the gap record, and postgres returned a duplicate key error - despite the row id in question having been selected by postgres, NOT kine.

I'll have to do some research to figure out where this needs to be fixed. Apparently SERIAL PRIMARY KEY in postgres does not work the same as INTEGER AUTO_INCREMENT and INTEGER PRIMARY KEY AUTOINCREMENT on mysql and sqlite, which was our expectation.

Apparently this is due to how postgres implements auto-increment using sequences - the next number in the sequence is retrieved at the start of the insert operation, but not used until the end. Other engines assign the auto-increment id at the end of the operation, based on the current max value of the row at the time the operation completes.
In the above example, sqlite and mysql would have assigned the row ids sequentially by the order they completed, not the order they started - and kine's expectations around linear ordering would be met.
I'm going to have to think about how to handle this without creating further performance regressions on postgres.

2023-10-20 15:02:26.232 UTC k3s k3s [16979]DETAIL: parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1319122', $6 = '0', $7 = '
2023-10-20 15:02:26.246 UTC k3s k3s [16979]DETAIL: parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:26.599 UTC k3s k3s [17542]DETAIL: parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:32.442 UTC k3s k3s [17863]DETAIL: parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:33.499 UTC k3s k3s [17863]DETAIL: parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 'f'
2023-10-20 15:02:33.695 UTC k3s k3s [17863]DETAIL: parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = 't'
2023-10-20 15:02:33.697 UTC k3s k3s [17863]DETAIL: parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1319122', $6 = '0', $7 = '

@brandond thanks for the analysis, could you please help me to understand. why same id is used in my testcase? if we assume there was gap key inserted? combining logs from api audit logs,
we can see this insert failed

2023-10-20 15:02:26.232 UTC k3s k3s [16979]DETAIL: parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1319122', $6 = '0', $7 = '

{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"9ce9f005-3e39-4e91-a254-aaff9296ed66","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/pc/configmaps?fieldManager=helm","verb":"create","user":{"username":"system:admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["<IP_ADDRESS>"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"configmaps","namespace":"pc","name":"yang-provider-confd-config","apiVersion":"v1"},"responseStatus":{"metadata":{},"status":"Failure","message":"configmaps "yang-provider-confd-config" already exists","reason":"AlreadyExists","details":{"name":"yang-provider-confd-config","kind":"configmaps"},"code":409},"requestReceivedTimestamp":"2023-10-20T15:02:26.216425Z","stageTimestamp":"2023-10-20T15:02:26.247106Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
and this one worked

2023-10-20 15:02:33.697 UTC k3s k3s [17863]DETAIL: parameters: $1 = '/registry/configmaps/pc/yang-provider-confd-config', $2 = '1', $3 = '0', $4 = '0', $5 = '1319122', $6 = '0', $7 = '

{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"2f3d09c8-7abc-4146-8ab2-5595b85c56d4","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/pc/configmaps?fieldManager=helm","verb":"create","user":{"username":"system:admin","groups":["system:masters","system:authenticated"]},"sourceIPs":["<IP_ADDRESS>"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"configmaps","namespace":"pc","name":"yang-provider-confd-config","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":201},"requestReceivedTimestamp":"2023-10-20T15:02:33.681942Z","stageTimestamp":"2023-10-20T15:02:33.712285Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}

I stepped through the logic and logs above. I'm not sure what ID you're referring to. Are you talking about the create_revision field? That's just the current max revision at the time the entry is inserted. That's how the mvcc model works.

This is painful to reproduce because it skirts the edge of what the nodes can handle resource wise but you can see some of the behavior here where pods are stuck terminating on the cluster.


Variants terminal color example partly missing

This example describes pattern-matching of polymorphic variant types with # prefix, however, the example does not show its usage anywhere:

But the source file contains (what seems to be) the correct example: https://github.com/realworldocaml/examples/blob/master/code/variants-termcol-fixed/terminal_color.ml


feat(PermissionFlagsBits): add CreateGuildExpressions

Please describe the changes this PR makes and why it should be merged:
If applicable, please reference Discord API Docs PRs or commits that influenced this PR:

discord/discord-api-docs#6120

Superseded by #790.


Game broken

When attempting to access this at https://githubschool.github.io/github-games-zmpanda, I am getting a 404. This could be caused by a couple things:

GitHub pages needs to be enabled on master. You can fix this in the repository settings.
the index.html file is incorrectly named inde.html. We will fix this together in class.

Can you please fix the first bullet @zmpanda?

fixed


BUG: Inline reference format issue

Version (please complete the following information):

OS: MacOS
Browser: Arc
Web Clipper version: Version 0.10.5
Obsidian version: 1.7.7

Inline reference format issue
When i clip a note into obsidian with reference links the in line reference do not format well in the md file. The reference brackets are line broken into separate lines instead of being in the same line.
For example
current format

...text
referencenumber

The current format creates unnecessary need for manual clean up after clipping. Is there a way/work around to adjust in settings or some formatting changes?
The issue seems to be mostly arising on perplexity.ai webpages
Expected behavior

...text referencenumber

URLs where the bug occurs
https://www.perplexity.ai/search/about-sub-tomogram-averaging-RZNSnKj4T..Ws.vaU1ZGWg
To reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Your template file
Default

Thank you for opening this issue! I have created a pr to address it :)
https://github.com/obsidianmd/obsidian-clipper/pull/266


[Usage]: The seed in vllm.SamplingParams and vllm.LLM

Your current environment
vllm==0.4.0
How would you like to use vllm
I notice that there are two seeds when using vllm.
The first one is in vllm.LLM.
https://docs.vllm.ai/en/latest/_modules/vllm/entrypoints/llm.html#LLM
The second one is in vllm.SamplingParams.
https://docs.vllm.ai/en/latest/_modules/vllm/sampling_params.html#SamplingParams
I am wondering what are the differences between these two.

LLM.seed: system level random seed,
e.g. https://github.com/vllm-project/vllm/blob/main/vllm/worker/worker.py#L179
vllm.SamplingParams.seed: request level random seed
e.g https://github.com/vllm-project/vllm/blob/main/vllm/model_executor/sampling_metadata.py#L486

Thank you!
Looks like vllm.LLM is for:
 random.seed(seed)
 np.random.seed(seed)
 torch.manual_seed(seed)

https://github.com/vllm-project/vllm/blob/ea9fa160e3b47e0b8aa273f3eb2be410bd1ccab5/vllm/model_executor/utils.py#L9-L14


Tap listener breaks drag on Android

If you have a carousel that you're listening for dragleft, dragright, and release on, and then you also have tap listeners on children in that carousel release is called prematurely whenever the user's finger enters the child element (even though they're still dragging in the carousel.)
Any thoughts on why this would happen?

Im going to close this since drag was removed in v2


Error when installing php 5,6

Hello,
I am having an issue when installing php 5.6 with homebrew:
Last 15 lines from<EMAIL_ADDRESS>typedef struct rsa_st RSA;
^
/private/tmp/php@5.6-20191122-43852-14kluu2/php-5.6.40/ext/openssl/openssl.c:3619:6: error: incomplete definition of type 'struct rsa_st'
OPENSSL_PKEY_SET_BN(Z_ARRVAL_PP(data), rsa, d);
^                                      ~~~
/private/tmp/php@5.6-20191122-43852-14kluu2/php-5.6.40/ext/openssl/openssl.c:3548:9: note: expanded from macro 'OPENSSL_PKEY_SET_BN'
_type->_name = BN_bin2bn(
~~~~~^
/usr/local/opt/openssl@1.1/include/openssl/ossl_typ.h:110:16: note: forward declaration of 'struct rsa_st'
typedef struct rsa_st RSA;
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make: *** [ext/openssl/openssl.lo] Error 1
make: *** Waiting for unfinished jobs....
Can you please provide some help?
OS: High Sierra
Brew version:
Homebrew 2.1.16
Homebrew/homebrew-core (git revision feec; last commit 2019-11-22)
Thanks in advance
Luis Dias

I just migrated my files to a new macOS machine, which is already running macOS 10.15 Catalina (previously I was on 10.14 Mojave). After running brew update && brew upgrade on the new system I have no OpenSSL 1.0.x available.
dyld: Library not loaded: /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib
  Referenced from<EMAIL_ADDRESS>  Reason: image not found
Abort trap: 6

I haven't found a way to install the 1.0.x version of OpenSSL that PHP 5.6 requires, and compiling from source results in the same errors you're seeing.
This is the same underlying issue as #9 but I don't see a way to work around it if your system does not have OpenSSL 1.0.x available. My next step will be to try compiling OpenSSL 1.0.2t from source: https://www.openssl.org/source/ and then recompiling this<EMAIL_ADDRESS>pointing at that version.

Just noticed that the OpenSSL (1.0.x) formula was recently removed from homebrew-core: https://github.com/Homebrew/homebrew-core/pull/46876

Hi,
Thank you for the reply.
Do you think you'll be able to fix the issue?
Regards,
Luis Dias

Similar Issue on
OS: High Sierra
ast 15 lines from<EMAIL_ADDRESS>typedef struct rsa_st RSA;                ^ /private/tmp/php@5.6-20191129-21483-2dg4kv/php-5.6.40/ext/openssl/openssl.c:3619:6: error: incomplete definition of type 'struct rsa_st'                                         OPENSSL_PKEY_SET_BN(Z_ARRVAL_PP(data), rsa, d);                                         ^                                      ~~~ /private/tmp/php@5.6-20191129-21483-2dg4kv/php-5.6.40/ext/openssl/openssl.c:3548:9: note: expanded from macro 'OPENSSL_PKEY_SET_BN'                         _type->_name = BN_bin2bn(                                                                       \                         ~~~~~^ /usr/local/opt/openssl@1.1/include/openssl/ossl_typ.h:110:16: note: forward declaration of 'struct rsa_st' typedef struct rsa_st RSA;                ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. make: *** [ext/openssl/openssl.lo] Error 1 make: *** Waiting for unfinished jobs....

Any solution to this issue?

We won't be able to provide support to older macOS version (other than Catalina). Sorry about this.

Figured it out... I just had to find libcrypto.1.0.0.dylib and libssl.1.0.0.dylib elsewhere on my mac and copy them over to the spots where they were missing...
==> Postinstalling<EMAIL_ADDRESS>==><EMAIL_ADDRESS>config-set php_ini /usr/local/etc/php/5.6/php.ini system
Last 15 lines from<EMAIL_ADDRESS>2019-12-23 10:14:49 -0700
<EMAIL_ADDRESS>config-set
php_ini
/usr/local/etc/php/5.6/php.ini
system
dyld: Library not loaded: /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib
  Referenced from<EMAIL_ADDRESS>  Reason: image not found
$ find / -name "libcrypto.1.0.0.dylib"
(Output omitted)
$ sudo cp /usr/local/Cellar/openssl/1.0.2r/lib/libcrypto.1.0.0.dylib /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylibphp
$ brew postinstall<EMAIL_ADDRESS>==> Postinstalling<EMAIL_ADDRESS>==><EMAIL_ADDRESS>config-set php_ini /usr/local/etc/php/5.6/php.ini system
Last 15 lines from<EMAIL_ADDRESS>2019-12-23 10:14:49 -0700
<EMAIL_ADDRESS>config-set
php_ini
/usr/local/etc/php/5.6/php.ini
system
dyld: Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
  Referenced from<EMAIL_ADDRESS>  Reason: image not found
$ find / -name "libssl.1.0.0.dylib"
(Output omitted)
$ sudo cp /usr/local/Cellar/openssl/1.0.2r/lib/libssl.1.0.0.dylib /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
$ brew postinstall<EMAIL_ADDRESS>==> Postinstalling<EMAIL_ADDRESS>==><EMAIL_ADDRESS>config-set php_ini /usr/local/etc/php/5.6/php.ini system
==><EMAIL_ADDRESS>config-set php_dir<EMAIL_ADDRESS>system
==><EMAIL_ADDRESS>config-set doc_dir<EMAIL_ADDRESS>system
==><EMAIL_ADDRESS>config-set ext_dir /usr/local/lib/php/pecl/20131226 system
==><EMAIL_ADDRESS>config-set bin_dir<EMAIL_ADDRESS>system
==><EMAIL_ADDRESS>config-set data_dir<EMAIL_ADDRESS>system
==><EMAIL_ADDRESS>config-set cfg_dir<EMAIL_ADDRESS>system
==><EMAIL_ADDRESS>config-set www_dir<EMAIL_ADDRESS>system
==><EMAIL_ADDRESS>config-set man_dir /usr/local/share/man system
==><EMAIL_ADDRESS>config-set test_dir<EMAIL_ADDRESS>system
==><EMAIL_ADDRESS>config-set php_bin<EMAIL_ADDRESS>system
==><EMAIL_ADDRESS>update-channels
$ brew link<EMAIL_ADDRESS>--force
Linking<EMAIL_ADDRESS>25 symlinks created

If you need to have this software first in your PATH instead consider running:
  echo 'export PATH="/usr/local/opt/php@5.6/bin:$PATH"' >> ~/.bash_profile
  echo 'export PATH="/usr/local/opt/php@5.6/sbin:$PATH"' >> ~/.bash_profile
$ php -v
PHP 5.6.40 (cli) (built: Apr 23 2019 11:14:34)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

Thanks! But this works ONLY if you have<EMAIL_ADDRESS>in Cellar already. So better get it somewhere and keep it, alongside with these two openssl files and this manual, lol.

See my comment here: https://github.com/eXolnet/homebrew-deprecated/issues/14#issuecomment-583787512

Yes and thank you! If you are looking to run php5.6 and, like me, you need php7.x also, you will need to have two versions os openssl at hand. Don't bother trying to get homebrew to do that for you because it will not. Simply copy libraries to the correct path (as suggested above) and you will have it.

Hello, I have tried almost everything to solve this. None of the above suggestions works for me.
I dont have php5.6 installed anymore and Im not able to install it with brew. Apache works fine, php7.1 also works. But php5.6 (the one I need) is not.
Anyone suggestions?
Thanks!

@amichia I added an answer here on what worked for me: https://github.com/eXolnet/homebrew-deprecated/issues/23#issuecomment-698574602


Updated assert_character_scalar() & assert_s3_class() with cli::cli_abort() messaging

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.
Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the main branch until you have checked off each task.

[x] Place Closes #375 and closes #377 into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
[x] Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
[x] Updated relevant unit tests or have written new unit tests, which should consider realistic data scenarios and edge cases, e.g. empty datasets, errors, boundary cases etc. - See Unit Test Guide
[x] If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
[x] Update to all relevant roxygen headers and examples, including keywords and families. Refer to the categorization of functions to tag appropriate keyword/family.
[x] Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
[x] Address any updates needed for vignettes and/or templates
[x] Update NEWS.md under the header # admiral (development version) if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
[x] Build admiral site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
[x] Address or fix all lintr warnings and errors - lintr::lint_package()
[x] Run R CMD check locally and address all errors and warnings - devtools::check()
[x] Link the issue in the Development Section on the right hand side.
[x] Address all merge conflicts and resolve appropriately
[x] Pat yourself on the back for a job well done! Much love to your accomplishment!

@ddsjoberg looks good, only comment I have is for assert_character_scalar we use the .val option which users separator "and" for last 2 values returned, can this be replaced with "or"??
Argument `msg_type` must be equal to one of "warning" and "error".

I tried replacing .val with .or but then the values aren't quoted!
Argument `msg_type` must be equal to one of warning or error.

Thank you @millerg23 for reviewing!!
I agree, "or" would be preferable when the values are properly quoted. Here are a few options:

Stick with it as it is, since the message is clear enough and we get nice quotations and colors.
Use {.or} so we get "or" instead of "and" in the list. But we won't get quotations or coloring.
Use rlang::arg_match0() function that does both quoting and coloring (and even adds on improved messaging including what the user passed that is not valid). But we can't modify the error message.

check_valid_fruit <- function(fruit) {
    rlang::arg_match0(fruit, c("apples", "bananas"))
}

check_valid_fruit("apples")
#> [1] "apples"
check_valid_fruit("lemons")
#> Error in `check_valid_fruit()`:
#> ! `fruit` must be one of "apples" or "bananas", not "lemons".

The last option is to change the default behavior of {.val} by creating a div container and defining different behavior. Admittedly, I've steered away from this because I friend told me they did this then {cli} made a breaking change to the implementation and it broke their code. But it is the solution that gets us exactly what we are looking for.

# define a div and change the .val instructions.
divid <- cli::cli_div(theme = list(.val = list("vec-last" = ", or ")))
cli::cli_text("{.val {letters[1:3]}}")
#> "a", "b", or "c"
cli::cli_end(divid)

# testing that the div is closed after `testing()` function stops execution
testing <- function() {
  divid <- cli::cli_div(theme = list(.val = list("vec-last" = ", or ")))
  cli::cli_abort("{.val {letters[1:3]}}")
}
testing()
#> Error in `testing()`:
#> ! "a", "b", or "c"

# reverts back to default "and" messaging
cli::cli_text("{.val {letters[1:3]}}")
#> "a", "b", and "c"

I am fine with any of these solutions as each of them provide clear messaging to the user. What do you all think?

@ddsjoberg thanks for providing the options, I think I prefer option 3 for assert_character_scalar. Would discount option 2, my initial thoughts was along the lines of option 4, but as you say may cause us issues down the line.
So for me in order of preference 3 > 4 > 1 > 2, but won't lose sleep over the option we choose ;-)

Could we hold off and discuss on Wednesday! I really want to get more involved, but the study grind is punishing right now :(.

Could we hold off and discuss on Wednesday! I really want to get more involved, but the study grind is punishing right now :(.

Sure @bms63 !

@ddsjoberg thanks for providing the options, I think I prefer option 3 for assert_character_scalar. Would discount option 2, my initial thoughts was along the lines of option 4, but as you say may cause us issues down the line. So for me in order of preference 3 > 4 > 1 > 2, but won't lose sleep over the option we choose ;-)

3 >>> 1 > 4 > 2 is my preferred order. I think that retaining the "standard" error message is ok, especially for a simple case like assert_character_scalar(). I would veer away from something more complicated like @ddsjoberg described in 4 as this may involve more maintenance for not much practical gain.

The last option is to change the default behavior of {.val} by creating a div container and defining different behavior. Admittedly, I've steered away from this because I friend told me they did this then {cli} made a breaking change to the implementation and it broke their code. But it is the solution that gets us exactly what we are looking for.

FYI I asked my friend about this and they were doing two things at once. Building new cli commands like this {.xxx arg} and changing the divid. The breaking change they experienced was from defining new cli commands, not the divid change. Also, this was a number of years ago already. With that in mind, I updated the error message to use the modified cli_div() to get the exact message we want.

Why has the content of the error messages been changed?
Before we had:
> assert_character_scalar(arg <- c("first", "last"), values = c("first", "last"))
Error in `assert_character_scalar()`:
! `arg` must be a character scalar but is a character vector of length 2
Run `rlang::last_trace()` to see where the error occurred.
> assert_character_scalar(arg <- 1, values = c("first", "last"))
Error in `assert_character_scalar()`:
! `arg` must be a character scalar but is `1`
Run `rlang::last_trace()` to see where the error occurred.
> assert_character_scalar(arg <- "1", values = c("first", "last"))
Error in `assert_character_scalar()`:
! `arg` must be one of 'first' or 'last' but is '1'
Run `rlang::last_trace()` to see where the error occurred.

And now we have:
> assert_character_scalar(arg <- c("first", "last"), values = c("first", "last"))
Error:
! Argument `arg <- c("first", "last")` must be a scalar of class <character> and equal to one of
  "first" or "last".
Run `rlang::last_trace()` to see where the error occurred.
> assert_character_scalar(arg <- 1, values = c("first", "last"))
Error:
! Argument `arg <- 1` must be a scalar of class <character> and equal to one of "first" or "last".
Run `rlang::last_trace()` to see where the error occurred.
> assert_character_scalar(arg <- "1", values = c("first", "last"))
Error:
! Argument `arg <- "1"` must be a scalar of class <character> and equal to one of "first" or
  "last".
Run `rlang::last_trace()` to see where the error occurred.

The new messages are longer but contain less information. The message is always the same regardless of what caused the failure.
I would consider the old messages more user friendly.
Could we use cli_abort() but keep the old content of the messages?


Unexpected behavior on Input event

Version
3.2.21
Reproduction link
sfc.vuejs.org/
Steps to reproduce
if you type a number greater than 45 in this example, it lets you keep typing after the condition is met once.
after the condition is met once it basically ignores the value prop in MyInput.
What is expected?
expected to repeatedly get the same value (45) when the input value is greater than 45.
What is actually happening?
start typing numbers, when the condition is met and the value changes to 45 keep typing to see it being ignored.
it emits the correct event and the value ref is correct but it will get ignored.

I was applying a simple v-model and noticed the value doesnt apply even when the ref changed to the correct number and the event emitted the correct value.

This is intended behavior because the value on the parent doesn't change from 45 so the child doesn't update again. You need to force the value on the input to constrain it.


msl generator enhancements/fixes

pack/unpack nested constant buffer structs
support for write-only textures (only global ones for now)
better rt index support for msl generator

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: Vadim Shcherbakov:x: fatkasVadim Shcherbakov seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Pinging @billhollings so he can have a look.

Please make organizational mods I've suggested to use of BuiltInLayer. Then it's good to go.

Please make organizational mods I've suggested to use of BuiltInLayer. Then it's good to go.

could you please elaborate what mods are you referring to?

Please make organizational mods I've suggested to use of BuiltInLayer. Then it's good to go.

could you please elaborate what mods are you referring to?

See the two (now outdated) change requests I asked for above...which I've also summarized in the new change request I've made.

Good to go.

Thanks for review and contribution.
@billhollings FYI, I'm on vacation starting tomorrow.

Have a great vacation.
When are you back...just so we can plan for future PR's?

Thanks. I'm back 4th Jan.


show credentials openapi documentation in add/update credentials UI

similar to order catalog UI, the credentials openapi documentation link must be displayed in the UI.
the API method here https://github.com/eclipse-xpanse/xpanse/blob/0d54b787e4637904564b15b5ec44435c13d80fc9/modules/api/src/main/java/org/eclipse/xpanse/api/CredentialManageApi.java#L154 must be called to get the link .

let me do it


Update FIRDynamicLinkNetworking.m

Recreate the session to avoid crash when opening another or the same dynamic link (app already opened by a dynamic or have already processed one)
Thanks @rszalski for the solution!
Fix #5880

Changes looks good to me. Deferring to @paulb777 for approval

Thanks for the fix @marqroldan and thanks for the review @eldhosembabu.
Before merging I'd like to get a resolution to @ncooke3's question about reproduction.
Do either of you have that?  Thanks!

Thanks for the fix @marqroldan and thanks for the review @eldhosembabu.
Before merging I'd like to get a resolution to @ncooke3's question about reproduction.
Do either of you have that? Thanks!

@paulb777 Ironically enough, I was able to accidentally reproduce this issue while testing another dynamic links issue (on iOS14)! I was then able to apply @marqroldan 's proposed fix and the crash was avoided. 👍

Sounds good. I'll merge.
@ncooke3 (or anyone else on the thread). I'd a appreciate another PR with the appropriate update to https://github.com/firebase/firebase-ios-sdk/blob/master/FirebaseDynamicLinks/CHANGELOG.md


Suppress warning about circular require

Summary
Since #1117, the engine is loaded automatically.
However, this change also resulted in a circular reference warning when running the test.
Current behavior
In the case of automatically loading:

load "view_component" in Gemfile.
load "view_component/engine" in lib/view_component if defined Rails::Engine.
load "view_component" in lib/view_component/engine.
load "view_component/engine" in lib/view_component if defined Rails::Engine.

...oops, this is circular require :fearful:
In the case of manually loading:

load "view_component/engine" in Gemfile or config/application.rb.
load "view_component" in lib/view_component/engine.
load "view_component/engine" in lib/view_component if defined Rails::Engine.
load "view_component" in lib/view_component/engine.

...oops, this is circular require :fearful:
Behavior after the change
In the case of automatically loading:

load "view_component" in Gemfile.
load "view_component/engine" in lib/view_component if defined Rails::Engine && not defined ViewComponent::Engine.

Fixed circular require :angel: :heart:
In the case of manually loading:

load "view_component/engine" in Gemfile or config/application.rb.
load "view_component" in lib/view_component/engine unless defined ViewComponent::Base.

Fixed circular require :angel: :heart:
Other Information
This is warning about circular require:
% bundle exec rake
/home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/zeitwerk-2.5.0.beta5/lib/zeitwerk/kernel.rb:35: warning: /home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/zeitwerk-2.5.0.beta5/lib/zeitwerk/kernel.rb:35: warning: loading in progress, circular require considered harmful - /home/yhirano55/src/github.com/yhirano55/view_component/lib/view_component.rb
        from /home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in  `<main>'
        from /home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in  `select'
        from /home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:21:in  `block in <main>'
        from /home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:21:in  `require'
        from /home/yhirano55/src/github.com/yhirano55/view_component/test/generators/component_generator_test.rb:3:in  `<top (required)>'
        from /home/yhirano55/src/github.com/yhirano55/view_component/test/generators/component_generator_test.rb:3:in  `require'
        from /home/yhirano55/src/github.com/yhirano55/view_component/test/test_helper.rb:22:in  `<top (required)>'
        from /home/yhirano55/src/github.com/yhirano55/view_component/test/test_helper.rb:22:in  `require'
        from /home/yhirano55/src/github.com/yhirano55/view_component/test/sandbox/config/environment.rb:4:in  `<top (required)>'
        from /home/yhirano55/src/github.com/yhirano55/view_component/test/sandbox/config/environment.rb:4:in  `require'
        from /home/yhirano55/src/github.com/yhirano55/view_component/test/sandbox/config/application.rb:11:in  `<top (required)>'
        from /home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/zeitwerk-2.5.0.beta5/lib/zeitwerk/kernel.rb:35:in  `require'
        from /home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/zeitwerk-2.5.0.beta5/lib/zeitwerk/kernel.rb:35:in  `require'
        from /home/yhirano55/src/github.com/yhirano55/view_component/lib/view_component.rb:22:in  `<top (required)>'
        from /home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/zeitwerk-2.5.0.beta5/lib/zeitwerk/kernel.rb:35:in  `require'
        from /home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/zeitwerk-2.5.0.beta5/lib/zeitwerk/kernel.rb:35:in  `require'
        from /home/yhirano55/src/github.com/yhirano55/view_component/lib/view_component/engine.rb:4:in  `<top (required)>'
        from /home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/zeitwerk-2.5.0.beta5/lib/zeitwerk/kernel.rb:35:in  `require'
        from /home/yhirano55/src/github.com/yhirano55/view_component/vendor/bundle/ruby/2.7.0/gems/zeitwerk-2.5.0.beta5/lib/zeitwerk/kernel.rb:35:in  `require'

@yhirano55 thank you for all of your contributions! Would you like to join the project in the triage role? https://viewcomponent.org/CONTRIBUTING.html#triage

@joelhawksley Thank you for your review and merge. I appreciate it.

Would you like to join the project in the triage role?

Yes, I would like to. I'm so excited :smiley:


Command error dereferencing a URL

Issue description
V6 node not attempting to bid, getting this error repeatedly in the logs:
[2023-04-19 23:00:14] ERROR: Command error (PublishLocalStoreRemoteError): Dereferencing a URL did not result in a valid JSON-LD object. Possible causes are an inaccessible URL perhaps due to a same-origin policy (ensure the server uses CORS if you are using client-side JavaScript), too many redirects, a non-JSON response, or more than one HTTP Link Header was provided for a remote context.
Expected behavior
Actual behavior
Steps to reproduce the problem

Specifications

Node version: 6.0.6
Platform:
Node wallet:
Node libp2p identity:

Contact details

Email:

Error logs
Disclaimer
Please be aware that the issue reported on a public repository allows everyone to see your node logs, node details, and contact details. If you have any sensitive information, feel free to share it by sending an email to<EMAIL_ADDRESS>

Just wanted to add that I am getting similar error message after each "Inserting asset with assertion id" on 6.0.9.


Implement crash_info.assertion?

I never actually noticed this but ProcessState::assertion (which becomes crash_info.assertion in the schema) is never actually populated:
https://github.com/luser/rust-minidump/blob/ac28159bb83c33c4381af361681810daf243365b/minidump-processor/src/processor.rs#L207-L208
I have no idea if this is something breakpad/socorro currently generates/reads, if this was an experimental feature that went nowhere, or if we actually have that information but it isn't wired up in minidump-processor.

FWIW I don't think I've ever seen this field populated on socorro

Socorro doesn't do anything with that field including indexing it, so it's hard to tell what values it holds without downloading all the data and looking through it. I'm game for doing that if that helps.
I see assertion in minidump-stackwalk in a few places, but I don't know that code well enough to know whether the source data is missing or whether the extraction code is buggy.
https://github.com/mozilla-services/minidump-stackwalk/search?q=assertion
That's everything I know about that.

We did populate this field apparently, see here and here.

Since it's not indexed I guess technically not a parity issue. But yeah if that data's there we should presumably collect and expose it.

I was looking over all the streams today I noticed MinidumpAssertion, which is presumably what this field is for. We actually have a minimal implementation of it, but don't ever read it in minidump_processor. Either I accidentally deleted the code or it was never written.