Question: Erreur après mise a jour de core?

Il est possible que domoticz mettait simplement de côté les lignes invalides silencieusement quand j'ai décidé de les faire remonter (justement pour aider l'utilisateur a détecter un mauvais module ou lien). Mais je ne peux le dire avec certitude, je n'ai pas regardé le code de domoticz.

Je ne saurais dire, malheureusement mon domaine (software) commence là où le hardware fini :)

~1 erreur/minute sur le lien série c'est clairement beaucoup

tag ok, valeur ok, checksum ko

Failed to validate the checksum of line 'b'?PTARIF HC.. HC.. (None) | s1 780 0b1100001100 | truncated 12 0b1100  | computed 44 0b101100 , | expected 60 0b111100 <

tag ko, valeur ok, checksum inconnu

Cela confirme ma conclusion précédente, vous avez beaucoup de lignes incorrectes en provenance du lien série. Mon intégration doit pouvoir les gérer tout en continuant de fonctionner, c'était le but de la mise à jour et si vous avez de nouveau une erreur de type `Uncaught thread exception` (celle-ci stoppant l'execution de l'intégration) prévenez moi que je rajoute un correctif.

Maintenant concernant vos erreurs/trames incorrectes en provenance du lien série, je ne saurais dire... Est-ce votre Linky qui est défectueux ? Votre connexion TIC ? Votre module série ? Le cablage ? J'ai bien peur que le seul moyen de le savoir serait de changer un élément après l'autre jusqu'à identifier le coupable. Ou alors simplement conserver l'ensemble tel quel et laisser l'intégration mettre de côté les lignes problématiques :)

Erreur après mise a jour de core
Depuis la mise a jour de core de ce jour j'ai cette erreur:

ERROR (MainThread) [homeassistant.components.binary_sensor] linkytic: Not adding entity with invalid device info: Invalid device info {'default_manufacturer': 'ENEDIS', 'default_model': 'Compteur communiquant Linky', 'default_name': 'Linky', 'identifiers': {('linkytic', '8cf004887b4e5242b31780c04d6df0ee')}, 'manufacturer': None, 'model': None} for 'linkytic' config entry: device info needs to either describe a device, link to existing device or provide extra information.

Bonjour,

Idem chez moi depuis ce matin avec la mise à jour HA Core en 2023.9.0.

linkytic: Not adding entity with invalid device info: Invalid device info {'default_manufacturer': 'ENEDIS', 'default_model': 'Compteur communiquant Linky', 'default_name': 'Linky', 'identifiers': {('linkytic', 'XXXXXXXXXXXXXXXXXXXXX')}, 'manufacturer': 'ITRON', 'model': 'Compteur monophasé 60 A généralisation Linky G3 - arrivée puissance haute'} for 'linkytic' config entry: device info needs to either describe a device, link to existing device or provide extra information.

Merci

Effectivement chez moi aussi les entités sont toujours là, mais plus dans l'appareil. L'appareil est toujours là mais sans entités.

On dirait que la manière de déclarer l'identifiant de l'appareil n'est plus valide. Il faut que je regarde, pas certain de pouvoir faire ca dans l'immédiat mais merci d'avoir remonté le problème.

---

Il s'agit d'une erreur différente d'une mauvaise ligne lue sur le lien TIC qui peut être "normale" et non liée à l'intégration en elle même. Un exemple sur URL (1ère erreur).

Hello, je confirme je viens de voir le même souci exactement immediatement après maj core

La première erreur dans mes logs lié à l'appareil invalide date du 25 Août. On dirait que le problème existait avant la .9 mais est devenu visible que récemment.

Oui j'ai deja notice ce pb dans la version 2023.8.3 mais c'était revenu en faisant un refresh
jai d'ailleur essayé un downgrade de HA en cette version et j'ai toujours le pb.

Bon j'ai désormais les certitudes suivantes :

- Depuis la version du mois d'Août, Home Assistant n'aime plus la manière de déclarer l'appareil agrégeant les entités
- Ce n'était alors pas un problème bloquant : l'appareil était bien créé mais vide, sans entités rattachées et les entités continuaient de fonctionner dans leur coin (ce qui explique que je n'ai pas vu le problème plus tôt)
- Depuis la version 9 (de septembre) ce problème de déclaration d'appareil est devenu bloquant : les entités ne sont plus créés par Home Assistant à cause de leur lien invalide vers l'appareil

Par contre, je n'ai pas encore mis le doigt sur qu'est-ce qui fait que la déclaration de l'appareil n'est plus considérée comme valide... Je continue de chercher.

je viens d'ouvrir ma console ESX et je vois ca..
screen

je pense pas que ca t'aide mais sait on jamais

Cela devrait être corrigé avec la v2.0.6.

Pour ceux qui voudraient plus de détails :

- Les appareils sont maintenant catégorisés en 3 types par Home Assistant et chacun de ces types ont un ensemble de propriétés à respecter. C'est à dire qu'il n'est plus possible de renseigner celles qui nous arrangent et d'en mélanger certaines.
- La déclaration précédente de l'appareil définissait à la fois un `default_manufacturer` et un `manufacturer` ainsi qu'un `default_model` et un `model`. Les defaults étant des constantes au cas où l'ADCO dont le vrai constructeur et modèle sont dérivés une fois la ligne lue sur le lien série (voir entité "Adresse du compteur").
- Mélanger les 2 n'est plus permis et la correction a été de définir les `manufacturer`, `model` et `name` (afin de correspondre à la définition de type `Primary`) et de retirer les `default_manufacturer`, `default_model` et `default_name` qui ne sont pas accepté en type `Primary` mais seulement `Secondary`.

Merci d'avoir porté le problème à mon attention et pour votre patience.

En attente de vos retours pour fermer (ou non) cette issue !

cela semble bon de mon coté ! Merci encore Hekmon !
je pense me creer une instance HA differente specialement pour l'energie qui ne serait pas mise a jour, pour justement eviter cela... qu'en penses tu ?

Bonsoir,
Même problème en faisant la mise à jour ce matin.

Plusieurs traces dans les logs :

`Détails du journal (ERREUR)
Logger: homeassistant.components.binary_sensor
Source: helpers/entity_platform.py:621
Integration: Capteur binaire (documentation, issues)
First occurred: 21:01:06 (1 occurrences)
Last logged: 21:01:06

linkytic: Not adding entity with invalid device info: Invalid device info {'default_manufacturer': 'ENEDIS', 'default_model': 'Compteur communiquant Linky', 'default_name': 'Linky', 'identifiers': {('linkytic', '91352f6da5a194c179aae1534d533446')}, 'manufacturer': 'SAGEM / SAGEMCOM', 'model': None} for 'linkytic' config entry: device info needs to either describe a device, link to existing device or provide extra information.`

`Détails du journal (ERREUR)
Logger: root
Source: helpers/entity.py:876
First occurred: 21:01:06 (1 occurrences)
Last logged: 21:01:06

Uncaught thread exception
Traceback (most recent call last):
 File "/usr/local/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
 self.run()
 File "/config/custom_components/linkytic/serial_reader.py", line 144, in run
 notif_callback(forced_update)
 File "/config/custom_components/linkytic/sensor.py", line 807, in update_notification
 self.schedule_update_ha_state(force_refresh=True)
 File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 876, in schedule_update_ha_state
 self.hass.create_task(
 ^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'create_task'`

Que cela représente plus de travail de maintenance pour vous @ToyNBoys :D
Après si la fiabilité et la disponibilité des informations liées à l'énergie est importante voir critique, cela peut s'entendre j'imagine !

Mais mon avis est certainement biaisé car si quelque chose se casse... je n'ai qu'à le réparer sans forcément dépendre de quelqu'un d'autre. C'est un plus ;)

---

@wkup vous semblez utiliser la version 2.0.5, avez-vous essayé la version 2.0.6 mis en ligne il y a quelques minutes et indiqué 2 messages plus haut ?

Merci pour votre avis ! Je vais ptet juste faire un snapshot avant de faire une Maj HA et voila...
Oui cest important pour suivre ma conso et production et si vous etes en vacances ca peux etre chiant, nayant pas vos compétences dans ce domaine...
Merci encore en tout cas encore beau boulot !

@hekmon La 2.06 marche pour moi, merci pour la rapidité de la mise en place d'une solution

Bonjour,
Les données redescendent bien dorénavant sur les entités. Merci @hekmon pour cette réactivité et ce travail correctif de qualité.
Une remarque toutefois. La carte "Energie" de HA ne s'alimente pas de mon côté. Avez-vous constaté la même chose de votre côté ?
Merci

Salut, c'est ok de mon coté, regarde dans la "configuration de l'energie" voir si ton entité a pas sautée

Vu que le problème semble corrigé, je clos cette issue. Mais vous pouvez bien entendu continuer à discuter dessus si nécessaire.

Plusieurs Erreurs
Bonjour,
Déjà merci pour votre travail, depuis plusieurs jours j’essaye de faire fonctionner le soft sous home assistant mais j’ai plusieurs erreurs dans les logs et arrêt après 1 min ou 2 de fonctionnement…
Pouvez-vous m’aidez ?

1 erreur :

Logger: custom_components.linkytic.serial_reader
Source: custom_components/linkytic/serial_reader.py:112
Integration: Linky TIC (documentation, issues)
First occurred: 21:47:48 (2 occurrences)
Last logged: 21:48:59

Failed to validate the checksum of line 'b'ISOUSC 45 \x7f'': ISOUSC -> 45 (None) | s1 607 0b1001011111 | truncated 31 0b11111  | computed 63 0b111111 ? | expected 127 0b1111111

2 erreurs :

Uncaught thread exception
Traceback (most recent call last):
 File "/usr/local/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
 self.run()
 File "/config/custom_components/linkytic/serial_reader.py", line 112, in run
 tag = self._parse_line(line)
 ^^^^^^^^^^^^^^^^^^^^^^
 File "/config/custom_components/linkytic/serial_reader.py", line 295, in _parse_line
 self._validate_checksum(tag, timestamp, field_value, checksum)
 File "/config/custom_components/linkytic/serial_reader.py", line 334, in _validate_checksum
 raise InvalidChecksum(
 ^^^^^^^^^^^^^^^^
 File "/config/custom_components/linkytic/serial_reader.py", line 369, in __init__
 self.tag = tag.decode("ascii")
 ^^^^^^^^^^^^^^^^^^^
UnicodeDecodeError: 'ascii' codec can't decode byte 0xbf in position 2: ordinal not in range(128)

Merci par avance .

Bonjour @baby-scarf ,

Regardons cela ensemble.

**1ère erreur**
La première erreur tout d'abord, en soit elle n'a rien d'inquiétant. Chaque ligne sur la connexion série possède à la fin un checksum pour valider l'intégrité de la ligne (et permettre de détecter une ligne invalide et éviter la remontée d'une mauvaise information). Cela peut arriver de temps en temps d'avoir une ligne invalide pour diverses raisons (mauvaise qualité du lien série, perturbation électromagnétique changeant la valeur d'un bit, etc...). L'important est simplement de ne pas en avoir trop souvent (sinon le câble ou le module série devrait être examinés voir remplacés).

En y regardant de plus près, le checksum remonté par l'erreur semble être `0x7f` ce qui est normalement (c'est à dire d'après le standard Enedis)... impossible : celui-ci de devrait se trouver qu'entre `0x20` et `0x5f`. Il semble donc que la perturbation ait impacté les bits composant le checksum (le nom du tag `ISOUSC` et sa valeure `45` semblent elles être normales) et l'intégration a donc décidé de ne pas prendre en compte cette dernière ne pouvant la vérifier. Comportement normal donc.

**2eme erreur**
Concernant la seconde erreur, c'est elle qui vous cause problème dans le sens où elle arrête le thread de série car l'erreur n'est pas prévue. Cette dernière prend racine lors de la formation d'une erreur de lecture série (comme la première) mais n'arrive pas à finaliser la remontée de cette erreur (où vous auriez eu une erreur du même format que la première).

Le détails de la seconde erreur semble indiquer que cette fois ci le tag comporte des bits invalides, amenant la définition d'un seul caractère (`in position 2`) hors des valeurs possibles de l'encoding ASCII utilisé par ENEDIS sur le lien TIC.

**Donc ?**
Je vais regarder pour publier rapidement une nouvelle version gérant correctement la seconde erreur pour éviter le crash du thread de gestion de la connexion série (je n'avais encore jamais eu de problèmes à ce niveau là) : cela ne corrigera pas l'erreur en elle même mais, comme pour la première, cela permettra de mettre la ligne de côté et de continuer à traiter les suivantes : l'intégration continuera de fonctionner malgré ces erreurs.

Par contre... Je ne vous cache qu'il est hautement inhabituel d'avoir autant d'erreurs sur un lien série et en aussi peu de temps. Quel module TIC/série utilisez vous ? La connexion série entre le TIC du Linky et le module est-elle bien en place ? Le câble n'est-il pas abimé ? Y a-t-il une source de pollution électromagnétique proche ? (des câbles trop fins pourraient être simplement trop sensibles par rapport a des câbles gainés).

Pouvez-vous essayer la version 2.0.5 ? Elle devrait éviter l'arrêt de fonctionnement de l'intégration pour les cas comme votre seconde erreur.

Je vous encourage tout de même à surveiller les logs de l'intégration et les erreurs de validation de lignes (comme votre première erreur) : il peut arriver d'en avoir mais cela est sensé être des cas rares et isolés et non fréquents (cf mon dernier message).

Bonjour,

merci pour votre efficacité et rapidité, je vais essayé de répondre à vos questions.
J’utilise un module fabriqué par moi à base optocoupleur 814 et quelques résistances relié au linky avec du câble fin téléphone, pourtant ce module même fonctionné très bien avec domoticz.
si c’est vraiment mon module après plusieurs essais je le remplacerai par la suite.
Tous mon matériel est branché au niveau de tableau général proche de la freebox, un Rflink.
J’ai mis en place votre correction ce matin je vous tiens informer de la suite .

une question : est il possible de branché mon module directement sur le port GPIO du raspberry comme je fesais avant pour domoticz ?

Un log après 1 heure de fonctionnement :

Logger: custom_components.linkytic.serial_reader
Source: custom_components/linkytic/serial_reader.py:112
Integration: Linky TIC (documentation, issues)
First occurred: 06:44:57 (66 occurrences)
Last logged: 07:51:54

Failed to validate the checksum of line 'b'ISOUSC 45 \x7f'': ISOUSC -> 45 (None) | s1 607 0b1001011111 | truncated 31 0b11111  | computed 63 0b111111 ? | expected 127 0b1111111
Failed to validate the checksum of line 'b'\xbfPTARIF HC.. -> HC.. (None) | s1 908 0b1110001100 | truncated 12 0b1100  | computed 44 0b101100 , | expected 60 0b111100 HC.. (None) | s1 740 0b1011100100 | truncated 36 0b100100 $ | computed 68 0b1000100 D | expected 60 0b111100 HC.. (None) | s1 780 0b1100001100 | truncated 12 0b1100  | computed 44 0b101100 , | expected 60 0b111100 -> 000000 (None) | s1 1000 0b1111101000 | truncated 40 0b101000 ( | computed 72 0b1001000 H | expected 66 0b1000010 B

Bonjour @baby-scarf ,

Sans retour de votre part je me verrai contraint de fermer cette issue.


Question: scrollable modal opens at the end of the page?

@jradtilbrook thanks for the link! I just tested adding autofocus to the dialog itself, but it didn't seem to do anything. If you can give me an example of that working, I'd be happy to see if I can get working with Flux's modal.

scrollable modal opens at the end of the page
### Flux version

v1.1.6

### Livewire version

v3.6.1

### Tailwind version

v3.4.13

### Browser and Operating System

Safari on macOS

### What is the problem?

If a modal contains so much text that it needs to be scrolled and there is a link or button at the bottom, the focus jumps to it and the page is displayed from the bottom.

### Code snippets

 Edit profile

 Update profile
 Make changes to your personal details.

 Optat adis eum ad quam non nossequi offictatur? Qui odionse quamus reheni as dolento corersp elecest maximus net milisim quatiumquis es volorestia seque qui aut lab iduntib eaquidu ciligen daepro dit fugias doloremolent lacearci bla quam, cum vellabo ribusa vel et volupta ad quodiorit aceperum fugia simoluptur aut plam que vel eatur, ut volor simagnatur? Quideni ssitionsed quodis rerferuptas ella doluptate perest, ut volorpo rescimus doluptat acea iliquam, sentibu sdaniatiist, con prae repedi quamus nullorias quas essimus consed moluptae es aut perum doluptatur, id mostoreces idelibus dent mo optate ressimus, omnimag nimoles sunt, sini conseque consequae. Nis porrum, ulliqui ipsum consequo volorest hil imusandamus am quis sequiat iaecaborendi consequos non coneceribus quis quia exerferio ea cum ent, voluptaquis et ipsam quam hillit, sum sunt volorpos autem ium earchil eturit qui dolorro mincidignim faccum fugia nus illignis essitat empossequam dolupiendi conesciis deribus ea que num inullam quam conseque volum quam laborep tatempo raeculpa esed quiatust endicie ndanducima aut landae ra voluptios dolupta tiuntem. Simet latur arit, tem ati odit utescia spitatur? Aquunda consequia dolenih icimpor eiciam, comni commolo maximusam voles quam ea dis int adigendi aturiataqui ilignat inveruptas volorem rerum quis ea quuntot atempedit et aut autaquat.
 Hilit, omnite cupiendi ulpa quod quiandi taquame ntiandam, num et veliqui quam quibus accuptur adi omnis aris antinimin nihilit optur aborendipsam dolorio vendusa dipicabor aditi optur, ut aribusae sitati oditatat reptiatium quas por as molut omnihit, tet ipicienem ut aut aut fuga. Item nonsendias dunto essum utatio. Ugiatem olupis adit erspers pidunt quatem etus voloriam ut molestem et as ma quam et acillore, sunt.
 Us. Me re venis aut quam quae cum di dolupti aspidebis dolupiciatas aut aut perro tecto officiduciam rem sunt et omniendellit quiaspe riatur, accatetur?
 Arum et rem utata dolorum doluptaquam rem se qui odi consed ut quam re cores esent oditi ipsant volo venimpos et eum eneceperum di officia dolore etum reictur alignient ra simporrum faccum alitaqui officate volo temo enihil experio. Culluptas dem hillab int ad et occatis sequunt qui rest, quam rest, ium nia vitatemporum quaspicium asiminu llitis eos rem exerror ruptatia experit la pa si aut unt, si nonsequam elia nihic temolum ut quat.
 At enet qui omniend ipitaes nonsequ idesti incto exceperum volorum enisinum quia conet accum repti dus el incitate officilitat.
 Les eosam il ipsanientem il ipsaperi omnimi, si dus dis dellam, serit, occuptation porior aut as seque poreped quatur maiost, consequo et que doloremque pre, nossendia susda cus suntio. Idunt volo exeriatum volestrum voluptatium volupta tiorro blam est quiae vero dolor aut lab id est, quam, te poriore pelictio. Namus, comnimo te verum qui int alia nos velloriandam que nist doluptatur a nulpa quisci beris velia voluptatem id et oditincid qui utes ra verio. Ga. Nempos aut dolest faccae ea quamet rerissimusam res restrum ese et aut que dolore pro ipisque sintem. Udipici demquos ad quia dendem volorrum fugiaepudi cullabor sae minus, occusan imendae cepero ium liatqui dolore venim facessitius volut fugiaspit, quis aut am quam, qui volectem fuga. Animusciis et, tecum eumquib usandaest offic tem aceaquaest, solo conse ditium veri duntusaped molupiducidi dolorestrum dolupta epudicitae nonesci atetur aspel experrum, officipsam quas pe mo iligendantet que ventem iurest iuri adi aut molut re cum fuga. Fic totatium et es maximustent.
 Ame et repratum que earchit, cum voluptatam, ese aut rem dolor atem exeriatiusae rem doluptae solut estrum alique nonem volupic illecab istotatatur? Qui berescia pre coria vidio voluptaqui quae dolluptas alis rerum doluptatem que dolest ut que nobist quiaepe dignatibus debis molupta temquidunt qui dolupta sit doluptatias perume volo tem. Culpari te perro omnit es mos explant que nossum reptat quiam imaio doloreiume lacestet qui net que ped quis debit ma vendae rera quaeper natquis verum im is earciet eariam volorest, sim re odis et ipiendant as doluptium fuga. Edicae. Uritia prorectet, tem fugia que vollab ipiendi commodit harumqu undant rerfercim reris ut verrovid ut harcipsa cusdant doluptatem fuga. Ita pres sum hil imped eveliquis dus voluptur?
 Andis dolupture officta temporitati omnimpos andanda ntendio nserumquo officilique doloruntem ium voluptaquia siment experferatem nonsed et, suntis alicte consed quid ma sum ex etus solorescia dolut optaera quunditius, volum harumqu asitio eum qui omnimil lendae prorit re, voluptatis doluptae sae essincient as modipitiis rerum quam fugiatibus, simus quam, offictemque cus, sumquod ignimporum doluptas repudicto berumquas quaspic tem eos qui con cusa quis quae pora cuptios ime dolore volora numque consendio. Ut rem harumet excerrum est anditibus si id que pa vollend untiorro exceptate volorep eribus molore voluptat officia sperum as andae. Ugitas esciam, ommoloraes etus sit autes veligende int eatus.
 Borporum qui dus, con rest laboriae nessit exceperempor alita doluptatiat.

 HTML;
 }
}

### How do you expect it to work?

The modal should open from the top.

### Please confirm (incomplete submissions will not be addressed)

- [x] I have provided easy and step-by-step instructions to reproduce the bug.
- [x] I have provided code samples as text and NOT images.
- [x] I understand my bug report will be closed if I haven't met the criteria above.

@DonCamillo11 I think this is similar to URL

Have a look at this as a workaround: URL

@jeffchown tried this workaround, but doesn’t seem to work in my case

@DonCamillo11 thanks for reporting and the help @jeffchown! I'm going to close this as it's a duplicate of #854. If you could add a comment to that issue and mention your work around, that'd be great, thanks!

Autofocus in modals forcing screenreaders to the end of the modal
### Flux version

1.0.23

### Livewire version

3.5.12

### What is the problem?

When you use a Flux modal, it autofocuses whatever is actionable (like an input or a button) within the modal. This makes sense for a sighted user who can read the modal's content then proceed to interact with whatever actionable element is focused. However for a screenreader, unless the actionable element is the absolute first one in the modal the autofocus skips them over the regular flow in the modal. This means that in order to fully read a modal screenreaders have to scan backwards from the actionable element to any text elements (like headings or paragraphs) then navigate forward again which isn't very accessible since people with vision impairments can't see that there's more content to navigate to.

Originally reported in this discussion thread: URL

### Code snippets

On the site I'm trying to meet accessibility on, I have modals with a heading, text, then an action button at the bottom. However because of the autofocus functionality the user is automatically being forced to the bottom of my modal. You should be able to recreate this with any Flux modal with both text elements and actionable items, but since this ask for how to reproduce it, this is the exact code I've been using when testing this issue:

I've customized the modal component to allow me to have my close action as a button instead of a standard x (only change is to the close button section)

blade

 {{ $trigger }}

 class($classes) }}
 @if ($name) data-modal="{{ $name }}" @endif
 @if ($variant === 'flyout') data-flux-flyout @endif
 x-data
 @isset($__livewire)
 x-on:modal-show.document="
 if ($event.detail.name === @js($name) && ($event.detail.scope === @js($__livewire->getId()))) $el.showModal();
 if ($event.detail.name === @js($name) && (! $event.detail.scope)) $el.showModal();
 "
 x-on:modal-close.document="
 if ($event.detail.name === @js($name) && ($event.detail.scope === @js($__livewire->getId()))) $el.close();
 if (! $event.detail.name || ($event.detail.name === @js($name) && (! $event.detail.scope))) $el.close();
 "
 @else
 x-on:modal-show.document="if ($event.detail.name === @js($name) && (! $event.detail.scope)) $el.showModal()"
 x-on:modal-close.document="if (! $event.detail.name || ($event.detail.name === @js($name) && (! $event.detail.scope))) $el.close()"
 @endif

 {{ $slot }}

 {{-- start of my customization --}}
 @if($close_type == 'button')

 @elseif($closable)
 {{-- This "[&[hidden]]:block" hack is here to prevent this element from effecting classes like "space-y-6" --}}

 @endif
 {{-- end of my customization --}}

Then the modal I'm actually testing with looks like so:

blade

 View Help Text

 Average Fuel Economy

 The Fuel Economy rating displayed is an average for operation while in gasoline mode only. Actual total energy usage will vary depending on daily distances driven in relation to the vehicle’s EV-mode range, as PHEV vehicles switch over to gasoline mode once battery charge is exhausted.

My actual modal looks like this:
Image

### How do you expect it to work?

I would expect that the modal would allow the screenreader to focus on the first element first, then move through the modal in normal document flow instead of being autofocused and forced to skip around in the document flow in order to get all of the content out of a modal. Whether this is the ability to turn off autofocus in modals or choose which element gets focus first, either would work to allow developers to create accessible modals!

### Please confirm (incomplete submissions will not be addressed)

- [x] I have provided easy and step-by-step instructions to reproduce the bug.
- [x] I have provided code samples as text and NOT images.
- [x] I understand my bug report will be closed if I haven't met the criteria above.

I second that! There should be option to disable autofocus for inputs within modal. Espacially when modal is a flyout

In this example I have some text and images preceding the form and do not want to be focused on the form straight away.

One workaround may be to add:

at the top of your form (or in whatever position will best serve your modal.

For now we are going to add support for adding `:autofocus="false"` to turn off autofocus in modals.

I've investigated this and at the moment the focus is actually coming from the native Dialog element. It by default focuses the first focusable element in the dialog.

I can't find a simple way to disable the autofocus for the Dialog element. Instead there are a bunch of solutions similar to @jeffchown's which suggest to add a hidden input at the top of the Dialog which is focusable.

@stuininga1 do you have any experience with screen readers and the native Dialog element or any suggestions on how best to handle it?

@joshhanley I've run into something similar, I see MDN says you could add autofocus to the dialog itself to effectively disable. Does that mean we could actually get a `:autofocus="false"` attribute that does it this way?

Ah yes I initially implemented it in firefox and it worked. But now trying it in chrome, it does not 😭

@jradtilbrook ah bummer 😕 that would have been great if it worked across all browsers.

Only other thing I think we might be able to do is a autofocused "Skip to content" button like GitHub and Google have.

Hi everyone, adding autfocus to a different element inside the dialog works well when opening it. This way at least you get control on what gets it at first.

We've managed to add support so that dialog elements doing autofocus the first element by essentially adding a honeypot first element, that the dialog focuses, then we remove from the tab order. This ensures that a screenreader and user's focus is at the top of modal. Using `autofocus` on the dialog (if supported by the browser) or any input inside still works as expected.


Question: [Bug]: Incomplete tool calling response for pipeline-parallel vllm with ray?

My initial thoughts;

- URL -> Plugin needs to change the API to accept stateful logit processor
- URL -> Right now, I feel orthogonal (there are overlap, but the PR mentioned APIs are supposed to be used "with" logit processor, and this RFC is logit processor specific).
- URL seems like a implementation of second part.
- URL seems orthogonal (existing logit processors will just work)

[Bug]: Incomplete tool calling response for pipeline-parallel vllm with ray
### Your current environment

vllm v0.5.4

Setup A) single docker container with vllm, no pipeline-parallelism

docker run ... vllm/vllm-openai:v0.5.4 --model "meta-llama/Meta-Llama-3.1-70B-Instruct" --tensor-parallel-size 2 --max-model-len=4096

Setup B) two docker containers with ray + vllm (pipeline parallelism)

docker run -it ... --network host --entrypoint /bin/bash vllm/vllm-openai:v0.5.4

# start ray head node in one of the docker containers
ray start --head --disable-usage-stats

# start ray worker node in the other docker container
ray start --address=' :6379'

# start vllm in head node container
vllm serve "meta-llama/Meta-Llama-3.1-70B-Instruct" --tensor-parallel-size 1 --pipeline-parallel-size 2 --distributed-executor-backend ray --max-model-len=4096

The issue does not depend on the model; e.g. it also appears with `meta-llama/Meta-Llama-3-70B-Instruct` instead of Llama-3.1

### 🐛 Describe the bug

Without pipeline-parallelism, a request with tool calling is responded correctly with a valid tool call.
With pipeline-parallelism, the same request is responded with incomplete tool call (just a few tokens long, but still status 200).

Example request:

{
 "model": "meta-llama/Meta-Llama-3.1-70B-Instruct",
 "max_tokens": 200,
 "seed": 8,
 "messages": [
 {
 "role": "user",
 "content": "What is the weather like in Berlin?"
 }
 ],
 "tools": [
 {
 "type": "function",
 "function": {
 "name": "get_current_weather",
 "description": "Get the current weather",
 "parameters": {
 "type": "object",
 "properties": {
 "location": {
 "type": "string",
 "description": "The city and state, e.g. San Francisco, CA"
 },
 "format": {
 "type": "string",
 "enum": ["celsius", "fahrenheit"],
 "description": "The temperature unit to use. Infer this from the users location."
 }
 },
 "required": ["location", "format"]
 }
 }
 }
 ],
 "tool_choice": {"type": "function", "function": {"name": "get_current_weather"}}
}

Response for setup A (no pipeline-parallelism)

{
 "id": "chat-a9e517fd2f0e4ac3817896596c5cc907",
 "object": "chat.completion",
 "created": 1722929009,
 "model": "meta-llama/Meta-Llama-3.1-70B-Instruct",
 "choices": [
 {
 "index": 0,
 "message": {
 "role": "assistant",
 "content": "",
 "tool_calls": [
 {
 "id": "chatcmpl-tool-0b5f4340c31d42c19765aa5f755586a3",
 "type": "function",
 "function": {
 "name": "get_current_weather",
 "arguments": "{\"location\": \"Berlin\", \"format\": \"celsius\"}"
 }
 }
 ]
 },
 "logprobs": null,
 "finish_reason": "stop",
 "stop_reason": null
 }
 ],
 "usage": {
 "prompt_tokens": 251,
 "total_tokens": 265,
 "completion_tokens": 14
 }
}

The response for setup B (pipeline-parallelism with ray)

{
 "id": "chat-80f69a8c5403478ea0c75943e7bab3af",
 "object": "chat.completion",
 "created": 1722931399,
 "model": "meta-llama/Meta-Llama-3.1-70B-Instruct",
 "choices": [
 {
 "index": 0,
 "message": {
 "role": "assistant",
 "content": "",
 "tool_calls": [
 {
 "id": "chatcmpl-tool-b6517d27352947969bf3d3dc8b8c6b98",
 "type": "function",
 "function": {
 "name": "get_current_weather",
 "arguments": "{\"location"
 }
 }
 ]
 },
 "logprobs": null,
 "finish_reason": "stop",
 "stop_reason": null
 }
 ],
 "usage": {
 "prompt_tokens": 251,
 "total_tokens": 254,
 "completion_tokens": 3
 }
}

how about using a single node and pp size 2 ( so that it uses multiprocessing backend)? does it still have this issue?

I just tested it, but the bug appears there as well:
Setup C) one docker container with 2 GPUs (pipeline-parallel, no ray)

docker run ... vllm/vllm-openai:v0.5.4 --model "meta-llama/Meta-Llama-3.1-70B-Instruct" --tensor-parallel-size 1 --pipeline-parallel-size 2 --max-model-len=4096

again the incomplete response:

{
 "id": "chat-28622b0c3d074caead37fb5441ca2407",
 "object": "chat.completion",
 "created": 1722964614,
 "model": "meta-llama/Meta-Llama-3.1-70B-Instruct",
 "choices": [
 {
 "index": 0,
 "message": {
 "role": "assistant",
 "content": "",
 "tool_calls": [
 {
 "id": "chatcmpl-tool-9dfa147ec16245d7a8efd67ddfc6012f",
 "type": "function",
 "function": {
 "name": "get_current_weather",
 "arguments": "{\"location"
 }
 }
 ]
 },
 "logprobs": null,
 "finish_reason": "stop",
 "stop_reason": null
 }
 ],
 "usage": {
 "prompt_tokens": 251,
 "total_tokens": 254,
 "completion_tokens": 3
 }
}

I solved this, as you only need to add "min_tokens": **. I set it to 50 due to my completion length.

I did some investigation, the problem is quite deep. In the case of guided decoding we are using _stateful_ logits processors. However, in PP, the logits processors will get cloned when sent to the workers other than the driver workers. This is ok for the TP use cases since the logits processor is not cloned and the state lives as long as the sequence group does. This is an issue for beyond PP however, and will affect anything SPMD. For those cases though, one solution might be to have the logits processor live on the worker. Pinging @njhill as this is quite similar to the seed issue and he might have some suggestions on the best way to resolve it.

MP GPU Executor, [ ]
Rank: 0, [ ]
(VllmWorkerProcess pid=2199329) Rank: 1, [ ]

I think we need to overhaul logits processor part. it should not be a part of sampling parameter.

sampling parameter should just store the constraint, like regex or json schema. and the constraint decoding state (i.e. FSM state) should live in each sequence. The FSM itself, with masks for every state, should be retrieved from some cache that maps from regex to FSM.

Yes exactly

Yup agreed

We can keep the FSM as part of logits processor but map from sequence to FSM in the worker similar to torch Generator. Ideally this is done in a clean and future-proof way.

@rkooo567 You mention support for guided decoding in URL Is this something you're looking into?

not exactly, but to make it work with SPMD, I believe we need exactly the same solution. So I may look into it soon. URL

also totally agreed with @youkaichao. I think that's the direction we should go (and what we wanted to achieve with URL

Yes @rkooo567 I think a lot of the stuff from SPMD is basically directly the same for PP.

There is already as a PR to make the stateful logit processor shareable

 URL

The idea is as described; pass around logit_processor factories instead of instantiation, and then each Sequence has its own instantiation of logit_processor

To make URL work with URL I think the `SequenceDataDelta` will leave the `SequenceData.logit_processors` untouched, and logit_processor will obtain the state from `SequenceData` as per usual once it has been updated with `SequenceDataDelta`

Meaning to say, probably minimal changes are required.

Absolutely, this has been planned for some time - a larger overhaul of how logits processors work is planned e.g. URL but is stalled a bit given how it needs to fit with other changes. I feel we can make some incremental improvements in the meantime, potentially starting with #5329 that @jon-chuang referenced.

Re needing the state to be in the worker for PP etc, I know it's also required for SPMD but imo should just be part of making the batches stateful (same for the torch.Generators).

@jon-chuang , I've been focusing on other issues in the past couple of weeks, but if this can be an incremental step on the way of a broader refactoring as @njhill mentioned, I'll sync this PR with main again.

We've encountered an issue, which I strongly assume is related to this.

When hosting Qwen/Qwen2-VL-72B-Instruct-AWQ in distributed mode via ray (with "--tensor-parallel-size 4 --pipeline-parallel-size 2") it is not possible to use guided_json mode. It does not return an error code, but stops generating after 3 tokens: ´´´{"content"
. Increasing the min_tokens as mentioned above via extra_body does not resolve the issue. When disabling "guided_json" the model generates a response without an issue. When not using "--pipeline-parallel-size 2" it is possible to use guided_json properly.

If needed, I can provide more details/output, but currently this looks quite related.

Setup C) one docker container with 2 GPUs (pipeline-parallel, no ray)

I'm removing the ray label since it appears in MP executor as well. cc @richardliaw

[RFC]: Improve guided decoding (logit_processor) APIs and performance.
### Motivation.

Currently, guided decoding & logit processor API is incomplete has has several issues. The RFC is intended to bring up problems and solutions. Some of issues may have been already addressed and there are PRs out already.

There are 3 major issues.
- It is not supported from SamplingParamters
- It is not possible to support batch/async logit processing.
- Upon failures, engine will die.

### Proposed Change.

API
----
guided decoding parameters are not supported with SamplingParams. It is addressed from URL

Performance
-------------
Currently, logit processors APIs are applied row by row blocking ( URL Instead, we can use parallel processing (e.g., ray or thread pool) to improve the logit processing performance. We are using this mechanism internally at Anyscale. We'd like to support this feature in OSS, and would like to improve logit processor API to support 1. async. 2. batching.

This requires logit processor to be
- stateful (to use a tool like Ray or thread pool). I think this PR URL is likely sufficient.
- async. We'd like to propose "prepare" API which can separate out compute_logits from preparing logits.

class LogitPostProcessor:
 def initialize(self, logit_processor_config: LogitProcessorConfig):
 """Initialize the post processor. Post processor may have states
 such as thread pool or Ray actors. It should be initialized
 here.
 """
 ...

 def prepare(
 self,
 seq_gruop_metadata_list: List[SequenceGroupMetadata]):
 """Asynchronously prepare logit masks."""
 ...

 def apply(self, logits: torch.Tensor) -> torch.Tensor:
 """Apply the prepared masks to a given logits."""
 ...

# For each model, we will have

def compute_logits(...):
 ....

def prepare_logits(seq_group_metadata_list):
 ....

`prepare` and `apply` assume 1:1 calls. E.g., once prepare is called, apply has to be called before another prepare is called. I think it is the safe assumption. Alternatively, we can make prepare return a class, but that will make interface surface larger, so I don't prefer that solution (but I am open to hear feedback!)

This is the example usage of the API

 # each model will have prepare_logits API
 self.model.prepare_logits(seq_group_metadata_list)
 hidden_states = model_executable(
 input_ids=input_tokens,
 positions=input_positions,
 kv_caches=kv_caches,
 attn_metadata=attn_metadata,
 **multi_modal_kwargs,
 )
 # Compute the logits. logit processors are applied here.
 logits = self.model.compute_logits(hidden_states, sampling_metadata)

We are also considering to upstream Ray based batch processing implementation with lmformatenforcer.

Failure Handling
----------------
When using a stateful logit processor, it is possible requests are failed. For example, if we use Ray, Ray actors can die. Or there could be user's schema issue that cannot be caught ahead of time.

When it happens, we should fail the seq_group immediately. We will introduce a new status "FINISHED_INTERNAL_ERROR = enum.auto()" to URL If any logit processor is failed, we will mark the relevant seq_group as failed, and the request will be aborted.

### Feedback Period.

_No response_

### CC List.

cc @simon-mo @Yard1

### Any Other Things.

_No response_

I have a few questions:

Can you elaborate on why you think placing the guided decoding parameters in the `SamplingParams` is a good idea? As I commented in #4130, I think they conceptually overlap with the logits processors implementing the guided decoding, which are already in the `SamplingParams`.

Do you maybe mean _stateless_? If not, what do you mean exactly?

Regarding the topic of statefulness: we probably don't want to limit ourselves to stateless logits processors. If we manage to make the API so that it is easy to implement stateful logits processors, we would already make things much better. E.g. I think that a very good thing to address would be to add infrastructure for pooling stateful objects and making it easy to define that one such object should not be shared across sequences and requests, or at least should be reset before being used.

Could you also please elaborate on the new `LogitsPostProcessor` API you propose? Is this the API to be implemented by logits processors? Or is this an API to be implemented by the models?

Are there maybe some type annotations missing for the return values of e.g. `prepare`? If this method does not return anything, this means the `LogitsPostProcessor` is stateful, right? Shouldn't we aim for a stateless design here, to make parallelization easier?

I might have misunderstood the proposal though. So, I'd be really happy if you could elaborate on it.

All in all, I would be very interested in improvements in this area, so I'm glad you're working on it!

It's like moving the functionality to the core API. Right now, it is implemented like an add-on (only working with OpenAI server), and it doesn't work with tools like URL (because we directly use the core API).

To improve time to prepare masks for json mode, we want to use parallel processing tools such as threadpool or ray. It requires the logit processor to be "stateful" because we don't want to recreate actors or threadpools everytime logit processos is requested (it should be created in `__init__`).

+1. I think it'd be an implementation of part 2.

It will replace `_apply_logit_processor` private API inside logit_processor.py. Right now, we apply logit mask row by row. We instead 1. find the relevant logit processor created. 2. logit_processor.prepare(seq_group_metadata_list) -> logit_processor.prepare(rows)

You are right the prep and apply is stateful. We can make it this way as well.

 masks = self.model.prepare_logits(seq_group_metadata_list)
 hidden_states = model_executable(
 input_ids=input_tokens,
 positions=input_positions,
 kv_caches=kv_caches,
 attn_metadata=attn_metadata,
 **multi_modal_kwargs,
 )
 # Compute the logits. logit processors are applied here.
 logits = self.model.compute_logits(hidden_states, sampling_metadata, masks)

But I found it easier to just make it fully stateful.

Hope this clarifies the proposal a little bit!

We should make this work with the following RFCs

@NadavShmayo URL
@mmoskal URL
@mmoskal URL
@maxdebayser @njhill URL
@lynkz-matt-psaltis URL

Some ideas:
- maybe `initialize()` can be async? the reason is that we don't start scheduling sequences, where the processor is still initializing (in case it takes a few seconds)
- add some sort of `free()` API so resources can be freed

With an additional post-sampling callback, this would subsume by SequenceController:

 def sampled(self, seq: 'Sequence', token_id: int,
 logprobs: Dict[int, 'Logprob']) -> Tuple[int, List[int], bool]:
 """
 Informs the controller a given token has been sampled.
 Returns the number of tokens to backtrack, the tokens to append,
 and whether to stop.
 """
 if token_id == seq.eos_token_id:
 return 0, [], True
 return 0, [token_id], False

I see. I found that API is limited for our particular use case because as you know it is applied after sampling is done (whereas we want to apply logit processor on final logits). It's great if we can subsume it.

I am open to it, but right now there's no specific use cases.

How is this guaranteed now?

@rkooo567 thanks, let me see if I understand it:

The idea is that the logits processors will be asked to `prepare` their masks asynchronously and in the meantime the model is going to be run. Once both are ready, the logits are computed by having the model call `apply`.

This means that the whole process needs to guarantee that there is one logits processor instance per request per sequence. Correct?

The implementation will need to be very careful to avoid contention issues.

---

Regarding the combination of this with the other PRs: I'm still struggling a bit to understand what general design we need. Let me explain:

The logits processors are now applied in the models; so the general signature of the operation is

compute_logits(hidden_states: Tensor, ...) -> Tensor

We want to support ff-tokens or backtracking (e.g. #4775). These things happen a few layers above the model and don't fit this API above.

So we're talking about different things in different abstraction layers at the same time.

Am I the only one? Is the design clear to you folks? If so, I would appreciate it a lot if someone could describe where which types of object would play which role.

@br3no One thing that took me a while to see is that there is only one `LogitPostProcessor` per LLMEngine - it handles logits for **all** sequences in the current batch.

There was some discussion of allowing a list of those, but IMHO it's easy to write a `LogitPostProcessor` that bundles an arbitrary number of ``LogitPostProcessor`s so I think there's no need to have a list of post processors in vLLM.

I'm the one asking for `ff_tokens` and `backtracking`, I think @rkooo567 is not doing this now.

@rkooo567 @simon-mo @mmoskal some additional thoughts after we talked offline yesterday:

It's a concern that the current support is kind of broken, it doesn't work for input batches or beam search due to the stateful/concurrency thing. So I wonder if we could prioritize some simpler immediate fixes for that along with the egregious performance overhead with json mode due to having to construct a new `CFGuide` instance every time. i.e. before the more significant rework to introduce batched application and the prepare step... WDYT?

A couple of other thoughts about the proposed interface:
- Why would we need an `initialize` method, couldn't a regular constructor be used for this?
- I'm not sure that it's a good idea to expose `List[SequenceGroupMetadata]` in this API ... I had assumed `SequenceGroupMetadata` is an internal datastructure that we want the freedom to change without breaking 3rd party LogitsProcessor impls. Probably should have some simpler dataclass or abstract class designed specifically for the API.

@mmoskal thanks for your answer! I also would like to support ff-tokens since I think this would contribute to alleviate the performance issues.

@njhill I’m not familiar with lm-format-enforcer, but for the Outlines processors now only the CFG one is problematic. The others are now stateless. Should we concentrate on a “fix” for the output_format: json issue? This would involve an object pool for the CFGGuide for that particular use case. Or am I missing other aspects here?

I also agree with it. I have impression the current interface is a little over-designed with some vague implementation in mind. For ff-tokens and backtracking, I would like to see the implementation otherwise it is very difficult to design the interface (that's why we punted). I think the interface I propose here is not going to bother us getting there (logit processor API also feels like it is not very stable API yet, so we have time to iterate).

Does it mean supporting stateful logit processor first (meaning merging the open PR)? I am okay with this.

I think regular constructor could work. The main reason was we need to pass the decode config to the logit processor, and since it is inside the model, the required change was big. I think constructor makes more sense actually.

Yeah it is a good point. for our internal impl, we just need seq_data, seq_ids, request_id, and sampling params.

Hi all, for those who are following this thread, I started benchmarking current performance for guided decoding in vLLM here #10046


Question: Some tokenizer exceptions not being applied?

Thanks again for the report, we've updated this in the internal attribute ruler data and added a test to `spacy-models`, so let's hope this is fixed in the next round of pipeline releases (probably pipeline version v3.8.0).

Some tokenizer exceptions not being applied
It seems like some of tokenizer exemption rules for the english models are not being applied. In the example below "yall" is correctly lemmatized as "you" + "all" but "doin" is lemmatized as "doin".

## How to reproduce the behaviour

import spacy

nlp = spacy.load("en_core_web_md")

string = "How are yall doin?"

for tok in nlp(string):
 print(tok.text, tok.lemma_)

Output

How how
are be
y you
all all
doin doin
? ?

## Environment

- **spaCy version:** 3.7.2
- **Platform:** Linux-6.5.10-200.fc38.x86_64-x86_64-with-glibc2.37
- **Python version:** 3.10.12
- **Pipelines:** en_core_web_md (3.7.0)

In spacy v2 the tokenizer and lemmatizer exceptions were both maintained as part of the tokenizer, but now in v3 the tokenizer exceptions are in the tokenizer settings and the lemmatizer settings are in the `attribute_ruler`. If you want to see all the details, look at the rules in `nlp.tokenizer.rules` and `nlp.get_pipe("attribute_ruler").patterns`. If you'd like, you can customize any of these rules/patterns in the `en_core_web_*` pipelines as necessary for your task.

The existing lemmatizer exception only applies to `"doin'"` and not `"doin"`, but looking again at the details there are some mistakes in the current rules, which have the lemma as "doing" instead of "do", so we'll get that updated for the next model release (probably v3.8.0).

The existing lemmatizer exception for `"doin'"` is not working for me either. This must be related to #13098 because after adding

nlp.get_pipe("attribute_ruler").add(patterns = [[{'LOWER': "doin'"}]], attrs= {'LEMMA': 'do'}, index= 0)

the lemmatization works as intended.

Ah, thanks for the note about that. My intention was that `NORM` would help here with `doin'` vs. `doin’`, but the tokenizer exceptions are more complicated than I remembered. I'll just revert all the `NORM` changes back to `LOWER` for the next model release so it goes back to the v3.6.0 behavior. (If these changes are causing problems for you, it should work fine to use the v3.6.0 `en_core*` models with v3.7.0.)

Thanks for the help, the v3.6.0 `en_core*` models indeed work better for my task.

I just went ahead and published updated v3.7 `en` models, which now should be available through `spacy download`.

Lemmatisation of "did" is no longer "do" in the context of n't
I just updated from spacy 3.6 to 3.7 and "did" is no longer getting lemmatised as "do" when followed by n't.

nlp = spacy.load("en_core_web_sm")
sent = "I didn't go to the bank at the weekend."
for tok in nlp(sent):
 print(tok.text, tok.lemma_)

Output:

I I
did did # lemma should be "do"
n't n't
go go
to to
the the
bank bank
at at
the the
weekend weekend
. .

## How to reproduce the behaviour

- **spaCy version:** 3.7.2
- **Platform:** Linux-6.2.0-1017-gcp-x86_64-with-glibc2.35
- **Python version:** 3.10.12
- **Pipelines:** en_core_web_sm (3.7.0)

hello @chrisjbryant
I think the error comes from the code you provided.
you should process the text with **nlp function** before doing the for loop like this:

`doc = nlp(sent)`

your code should look like this :

`nlp = spacy.load("en_core_web_sm")
sent = "I didn't go to the bank at the weekend."
doc = nlp(sent)

for tok in doc:
 print(tok.text, tok.lemma_)
`

`I -PRON-
did do
n't not
go go
to to
the the
bank bank
at at
the the
weekend weekend
. .
`

Ah! My bad, that was a mistake in my demo code above.

I did some more testing as the error appeared in my code when I upgraded spacy in my app, but when I test a clean spacy install, lemmatisation works as expected. So most likely not a spacy problem!

My bad, that was a typo in my example code. I have updated it now. The error is still present in spacy.

Hi @chrisjbryant, can you set up a fresh virtual environment and run this script there? I can't reproduce this. If I run

python
import spacy
print(spacy.__version__)
nlp = spacy.load("en_core_web_sm")
sent = "I didn't go to the bank at the weekend."
for tok in nlp(sent):
 print(tok.text, tok.lemma_)

my output is:

3.7.2
I I
did do
n't not
go go
to to
the the
bank bank
at at
the the
weekend weekend
. .

I was previously using a conda env, but just tried with venv and same result. :/

Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

3.7.2

... print(tok.text, tok.lemma_)
...
I I
did did
n't n't
go go
to to
the the
bank bank
at at
the the
weekend weekend
. .

Huh, after noticing I ran this with Python 3.9 I set up a clean venv with Python 3.10 - there I can reproduce this. We'll look into it.

I can confirm that this is a bug. A few of the attribute ruler patterns were switched from `LOWER` to `NORM` in v3.7.x (to generalize a bit better overall), but "did" is already normalized to "do" by the tokenizer, and then the "did n't" pattern no longer matches as intended.

You can add the old rule back to the current `en_core_*` models as a workaround:

python
nlp.get_pipe("attribute_ruler").add(
 patterns=[[{"TAG": "VBD", "LOWER": "did"}]],
 attrs={"POS": "AUX", "LEMMA": "do"},
 index=0,
)

Just to make sure, don't forget to check other cases too, since I now also recreated it with `hadn't`!

Yeah, we'll review all the changes. (The underlying idea was to use `NORM` to match more variants of contractions with apostrophes.)


Question: Hibernate regression in Quarkus 3.17.2 org.hibernate.bytecode.enhance.spi.EnhancementException fails to build?

@wcicola the present issue was fixed in URL which means it's fixed in Quarkus 3.17.6 (through #45235). I unfortunately forgot to close issues fixed in the latest ORM version, I'll get to it right now.

Could you please test this with Quarkus 3.17.6, and if your problem still occurs, open a new issue? Preferably, directly on hibernate.atlassian.net and with a reproducer based on this.

Thank you.

Hibernate regression in Quarkus 3.17.2 org.hibernate.bytecode.enhance.spi.EnhancementException fails to build
### Describe the bug

Hibernate regression in Quarkus 3.17.2

We have an entity that implements one or more interfaces. Those interface methods don't always map to a field in the class but to another method. This has worked fine in all versions of Quarkus (Hibernate) through 3.16.4, error started when we upgraded to 3.17.2, I did not try 3.17.0.

posh
[ERROR] Failed to execute goal io.quarkus.platform:quarkus-maven-plugin:3.17.2:build (default) on project json-view-schema-example: Failed to build quarkus application: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
[ERROR] [error]: Build step io.quarkus.deployment.steps.ClassTransformingBuildStep#handleClassTransformation threw an exception: java.lang.reflect.UndeclaredThrowableException
[ERROR] at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:862)
[ERROR] at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
[ERROR] at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
[ERROR] at org.jboss.threads.EnhancedQueueExecutor$Task.doRunWith(EnhancedQueueExecutor.java:2675)
[ERROR] at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2654)
[ERROR] at org.jboss.threads.EnhancedQueueExecutor.runThreadBody(EnhancedQueueExecutor.java:1627)
[ERROR] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1594)
[ERROR] at java.base/java.lang.Thread.run(Thread.java:1583)
[ERROR] at org.jboss.threads.JBossThread.run(JBossThread.java:499)
[ERROR] Caused by: java.util.concurrent.ExecutionException: org.hibernate.bytecode.enhance.spi.EnhancementException: Enhancement of [com.example.jsonview.model.Group] failed because no field named [x] could be found for property accessor method [getX]. To fix this, make sure all property accessor methods have a matching field.
[ERROR] at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
[ERROR] at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
[ERROR] at io.quarkus.deployment.steps.ClassTransformingBuildStep.handleClassTransformation(ClassTransformingBuildStep.java:273)
[ERROR] at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
[ERROR] at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)
[ERROR] ... 8 more
[ERROR] Caused by: org.hibernate.bytecode.enhance.spi.EnhancementException: Enhancement of [com.example.jsonview.model.Group] failed because no field named [x] could be found for property accessor method [getX]. To fix this, make sure all property accessor methods have a matching field.
[ERROR] at org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.checkUnsupportedAttributeNaming(EnhancerImpl.java:497)
[ERROR] at org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.doEnhance(EnhancerImpl.java:178)
[ERROR] at org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.lambda$enhance$1(EnhancerImpl.java:120)
[ERROR] at org.hibernate.bytecode.internal.bytebuddy.ByteBuddyState.rewrite(ByteBuddyState.java:166)
[ERROR] at org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.enhance(EnhancerImpl.java:120)
[ERROR] at io.quarkus.hibernate.orm.deployment.HibernateEntityEnhancer$HibernateEnhancingClassVisitor.hibernateEnhancement(HibernateEntityEnhancer.java:83)
[ERROR] at io.quarkus.hibernate.orm.deployment.HibernateEntityEnhancer$HibernateEnhancingClassVisitor.visitEnd(HibernateEntityEnhancer.java:76)
[ERROR] at org.objectweb.asm.ClassVisitor.visitEnd(ClassVisitor.java:395)
[ERROR] at io.quarkus.panache.common.deployment.visitors.PanacheEntityClassAccessorGenerationVisitor.visitEnd(PanacheEntityClassAccessorGenerationVisitor.java:126)
[ERROR] at org.objectweb.asm.ClassVisitor.visitEnd(ClassVisitor.java:395)
[ERROR] at org.objectweb.asm.ClassReader.accept(ClassReader.java:749)
[ERROR] at org.objectweb.asm.ClassReader.accept(ClassReader.java:425)
[ERROR] at io.quarkus.deployment.steps.ClassTransformingBuildStep.transformClass(ClassTransformingBuildStep.java:367)
[ERROR] at io.quarkus.deployment.steps.ClassTransformingBuildStep$2.call(ClassTransformingBuildStep.java:238)
[ERROR] at io.quarkus.deployment.steps.ClassTransformingBuildStep$2.call(ClassTransformingBuildStep.java:225)
[ERROR] at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
[ERROR] ... 7 more

Here is a reproducer app: json-view-schema-example.zip

### Expected behavior

Build should be successful like it has been until using Quarkus 3.17.2.

### Actual behavior

Build fails with org.hibernate.bytecode.enhance.spi.EnhancementException:

### How to Reproduce?

_No response_

### Output of `uname -a` or `ver`

_No response_

### Output of `java -version`

java 21.0.4 2024-07-16 LTS

### Quarkus version or git rev

_No response_

### Build tool (ie. output of `mvnw --version` or `gradlew --version`)

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)

### Additional information

_No response_

I can confirm this bug is limited to Quarkus 3.17.2 only, which uses hibernate 6.6.3.Final.

Quarkus 3.17.0 which uses hibernate 6.6.1.Final does not have this bug.

@geoand yes, this error is also triggered by the new check introduced by URL see my comment on the other issue for more details.

A possible workaround is annotating those methods with `jakarta.persistence.Transient`, or changing their name so they don't start with `is`, `get` or `set`.

I've added the link to the reproducer for this issue in the Hibernate issue I previously created, thank you @dhoffer for providing that and reporting the issue, we should address this case as well when refining the check.

Thanks for reporting. Closing as duplicate of #44863 , let's follow progress there.

org.hibernate.bytecode.enhance.spi.EnhancementException: Enhancement of [org.acme.domain.MyEntity] failed
### Describe the bug

Exception occurs during Build:
` org.hibernate.bytecode.enhance.spi.EnhancementException: Enhancement of [org.acme.domain.MyEntity] failed because no field named [modelType] could be found for property accessor method [getModelType]. To fix this, make sure all property accessor methods have a matching field.`

### Expected behavior

The Build should succeed.

### Actual behavior

When building the project:
ERROR] Caused by: java.util.concurrent.ExecutionException: org.hibernate.bytecode.enhance.spi.EnhancementException: Enhancement of [org.acme.domain.MyEntity] failed because no field named [modelType] could be found for property accessor method [getModelType]. To fix this, make sure all property accessor methods have a matching field.

### How to Reproduce?

Reproducer: URL
Just build the project with maven.
Simple Entity:

Java
@Entity
public class MyEntity {

 @Id
 private UUID id;

 public UUID getId() {
 return id;
 }

 public void setId(UUID id) {
 this.id = id;
 }

 public void getXXX() {
 }

 @PrePersist
 public void setId(){
 id = UUID.randomUUID();
 }

 public String getModelType() {
 return "MyEntity";
 }
}

After changing the PrePersist setter to a seperate name the build is working:

Java
@Entity
public class MyEntity {

 @Id
 private UUID id;

 public UUID getId() {
 return id;
 }

 public void setId(UUID id) {
 this.id = id;
 }

 public void getXXX() {
 }

 @PrePersist
 public void prePersistSetId(){
 id = UUID.randomUUID();
 }

 public String getModelType() {
 return "MyEntity";
 }
}

### Output of `uname -a` or `ver`

Darwin Mac-C6VD4H4XT3 24.1.0 Darwin Kernel Version 24.1.0: Thu Oct 10 21:00:32 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6030 arm64

### Output of `java -version`

openjdk version "21.0.5" 2024-10-15 OpenJDK Runtime Environment Homebrew (build 21.0.5) OpenJDK 64-Bit Server VM Homebrew (build 21.0.5, mixed mode, sharing)

### Quarkus version or git rev

3.17.2 --> hibernate-core 6.6.3

### Build tool (ie. output of `mvnw --version` or `gradlew --version`)

Maven home: /opt/homebrew/Cellar/maven/3.9.9/libexec Java version: 21.0.5, vendor: Homebrew, runtime: /opt/homebrew/Cellar/openjdk@21/21.0.5/libexec/openjdk.jdk/Contents/Home Default locale: de_DE, platform encoding: UTF-8 OS name: "mac os x", version: "15.1.1", arch: "aarch64", family: "mac"

### Additional information

@yrodiere Can you please check. Thx.
See: URL

Hello @KaiSuchomel, thank you for reporting the issue and providing a simple mapping which reproduces your problem.

The error you're facing is caused by a recent change in Hibernate's bytecode-enhancement logic: URL The new check is needed because support for bytecode enhanced entities with `AccessType.PROPERTY` (using getter/setter methods instead of fields) does not function properly unless the field names exactly match the method names - in Quarkus this can be especially problematic since enhancement is done at build-time and we expect all entities to be enhanced at runtime.

Using `setX`, where `X` is a persistent property name, as the method name in your entity classes is generally not a good idea, especially when using bytecode-enhancement, as the method could be mistaken as a setter for that field. So the "workaround" you found is more than valid and I would suggest keeping that as-is.

Regardless, I believe the check should in this case insce:

1. The entity is using `AccessType.FIELD`, since the `@Id` annotation is placed on the `id` field;
2. The pre-persist method `setId` corresponds to an actually existing field

We should open an issue on Hibernate ORM's Jira to keep track of this and possibly improve the check.

@geoand I believe so, yes, I've added a link to that issue and its reproducer to the ORM Jira - thanks for the ping.

I've recently encountered a similar issue that seems to be related, but haven't yet seen a report of this exact manifestation of it either here or on the Hibernate Jira.

If an entity:

1. Is mapped using `AccessType.PROPERTY`,
2. Extends a class with fields that are accessible to subclasses, and
3. Tries to map those accessible superclass fields using annotations on its own getters/setters

Then the build fails also with a similar EnhancementException.

I can put together a full repro project and/or post on the Hibernate Jira if it would help, but the only required code for reproduction is a Quarkus 3.17.2+ project using `quarkus-hibernate-orm` and with these two classes:

package test.entity;

import jakarta.persistence.MappedSuperclass;

@MappedSuperclass
public abstract class AbstractEntity {

 protected Long oid;
}

package test.entity;

import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.Id;

@Entity
public class EntityTest extends AbstractEntity {

 @Id
 @Column(name = "ID")
 public Long getOid() {

 return oid;
 }

 public void setOid(Long oid) {

 this.oid = oid;
 }
}

The result of `mvn package`:

[ERROR] Caused by: org.hibernate.bytecode.enhance.spi.EnhancementException: Enhancement of [test.entity.EntityTest] failed because no field named [oid] could be found for property accessor method [getOid]. To fix this, make sure all property accessor methods have a matching field.

Basically, the bytecode enhancement process seems to now be only considering fields declared in the same class that contains the getters/setters, whereas it previously detected inherited fields without issue. The same code builds fine using Quarkus 3.17.0 or lower.

@yrodiere @mbladel Many thanks! I'll get that put together and posted today.

We are discovering this issue in 3.21.2 again. It worked until 3.21.1 and started to fail in 3.21.2. Anyone else rediscovering this?

In our Environment the deployment is failing with the error again with quarkus 3.21.2. Running with quarkus 3.32.1.
@dhufnagel Have you a cretaed a reproducer?
May be the URL is causing the issue.

@dhufnagel @mbladel
I have enhance the reproducer: URL
With quarkus 3.21.1 everything is running, quarkus 3.21.2 is failing with:
`[ERROR] Caused by: org.hibernate.bytecode.enhance.spi.EnhancementException: Enhancement of [org.acme.domain.RevisionBase] failed because no field named [id] could be found for property accessor method [getId]. To fix this, make sure all property accessor methods have a matching field.`

I was out of Office and did. Not have the time to create a reproducer. But it seems to be related to the issue @mbladel is mentioning. We have an entity with a getSomething() method, where "something" is not a property but extract information from other properties. So I think in our case we track the mentioned issue.


Question: bug: Copying and pasting?

Hey @AlfSandoval

Thank you for providing the detailed report. The team will take a look into it.
It seems, that this is caused because of focus handling.

bug: Copying and pasting
### Version

1.30.0

### Describe the bug

I find copying and pasting code or content difficult, especially from Jupyter Notebook to the chat interface.

It ends up pasting new Jupyter cells within the notebook instead of pasting the copied content to the chat tab.

Copying and pasting code or content is difficult and frustrating. It has made the user experience awful.

### Expected behavior

I expected the copied content to be pasted on the chat tab instead it always pastes the created content on Jupyter notebook as a new cell.

### Additional context

_No response_

Thanks @chineidu I will make sure the product team sees this in the weekly community feedback report.

So this is a bug still going on. I though I was going crazy because each time I hit ctrl-v or paste something in the chat it duplicate the last cell of my jupyter notebook

I think Jupyter causes it. It's more like a Jupyter notebook bug.

@chineidu this issue is duplicated by another issue where I explained that this is not the fault of Cody but
of the jupyter plugin.
Have a look at my comment
 URL

@PriNova I think you can close this issue as well as this is not the fault of Cody.

Thank you @ichim-david for the support. I will close this issue.

bug: copy pasting in jupyter notebooks
Type: Bug

## Extension Information

- Cody Version: 1.45.1732320290
- VS Code Version: 1.93.1
- Extension Host: desktop

## Steps to Reproduce

1. Open a Jupyter Notebook in VS Code.
2. Copy content from a cell in the notebook.
3. Paste the content into the Cody chat window.
4. Observe duplication of cells in the notebook or issues with the paste action.

## Expected Behaviour

Content from the Jupyter Notebook should paste seamlessly into the Cody chat without causing duplication of cells in the notebook.

## Actual Behaviour

Copy-pasting from the Jupyter Notebook into the Cody chat causes duplication of cells in the notebook. Clicking off the notebook tab is required to paste content into Cody chat.

## Logs

Extension version: 1.45.1732320290
VS Code version: Cursor 0.43.3 (09a504fa3bdd3caa05bfe01b88bd2b79e283d240, 2024-11-24T21:46:28.029Z)
OS version: Windows_NT x64 10.0.22631
Modes:

 System Info

|Item|Value|
|---|---|
|CPUs|13th Gen Intel(R) Core(TM) i9-13950HX (32 x 2419)|
|GPU Status|2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off|
|Load (avg)|undefined|
|Memory (System)|63.76GB (31.32GB free)|
|Process Argv||
|Screen Reader|no|
|VM|0%|

@AlfredoSandovalx I just tried this issue and it seems to be a problem with how jupyter notebooks behave in VSCode.
I can reproduce your bug using Vs Code on a Mac with Cody
but I can also reproduce this bug by having Supermaven opened and trying to paste inside it's chat panel.
Try it yourself and see if that is not the case.

As such I would add an issue to the extension or VSCode rather than to Cody
cody-jupyter-paste
In this picture what I had in the paste registry was the content seen in the terminal, while triggering the paste action gave the same message as seen in the jupyter cells

@ichim-david You nailed it. Had this on Vscode, Cursor and windsurf. Will share w/ Vs.

I close this issue as resolved.

Thank you all for the help.


Question: Using Triton 3.2: ModuleNotFoundError: No module named 'triton.ops'?

What's your `triton` package version? The newest `triton` has removed `triton.ops`. You can use `pip install triton==3.0.0` to avoid this issue.

Using Triton 3.2: ModuleNotFoundError: No module named 'triton.ops'
I updated to Triton 3.2 and get the following error message

ModuleNotFoundError: No module named 'triton.ops'

The same issue as URL
Please downgrade triton to 3.0.0:
`pip install triton==3.0.0`

But Pytorch2.6.0+cu126 needs triton>=3.2.

Please consider support it.

Image

I just confirmed that PyTorch 2.6 + Triton 3.2 + latest ComfyUI + TeaCache (+ other nodes like GGUF) works, and it runs Wan much faster than uncompiled. OP's issue may be because some Python package or ComfyUI node is outdated. Next time please paste the full error log to help locate the problem

For triton 3.2, you need to update bitsandbytes to 0.45.3 and you should be fine.

I have the same problem. I tried upgrading to triton-windows today (iirc I had a slightly older version of Triton 3.2 running), but now many nodes in Comfy don't load anymore, asking for a missing Triton.Ops.

And I do have bitsandbytes==0.45.3 and I was able to run Wan & HV in Comfy with Torch.Compile, Teacache and Sageattention a few hours ago.

@CognitiveDiffusion Please paste the full error log to help locate the problem

Neither installation in comfyui nor manual downloading from github can be used.
Error message：Cannot import D:\anzhuanbao\shellagent\ComfyUI_windows_portable_nvidia\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-TeaCache-main module for custom nodes: No module named 'comfy.ldm.lightricks'

Uninstalling and fixing TeaCache nodes in comfyui failed

Image

Your ComfyUI version is too old. Please update your ComfyUI and try again.

That isn't it.

Same issue, I just uninstalled and reinstalled everything, entirely up to date. It seems it might have to do with this from my traceback:

ModuleNotFoundError: No module named 'triton.ops'

Cannot import /home/xxx/ComfyUI/custom_nodes/ComfyUI-TeaCache module for custom nodes: No module named 'triton.ops'

triton.ops seems to have been moved to triton-lang maybe?

Thank you very much for your help, the problem is completely solved after the update


Question: Inappropriate rebalances being selected?

Check if the max fee displayed is correct for you. Manually calculate the target channel future income (as `(base_fee + amount * fee_ppm) * econ_ratio`), subtract the source channel fee (as `base_fee + amount * fee_ppm`).

Inappropriate rebalances being selected
I'm currently testing with the config file settings:

econ_ratio: 0.5
lost_profit: true

... and have run the rebalancer with no further parameters specified via command line. Each time, it has selected routes that are inappropriate. For instance, rebalancing a target channel that I currently charge 30ppm with a source currently charging 200ppm.

Also, I've attempted to specify a source channel via command line without any further parameters, hoping regolancer would attempt to find an appropriate rebalance with any possible target channels fitting the liquidity criteria specified in config.json; however, it throws error "No source channels selected." Am I missing something here?

Thanks!

What was the max fee reported for the route? Does it match the formula here? Are you sure you specified the options correctly? Currently unknown options are ignored, I think it should be fixed to prevent mistakes.

The default liquidity limit is 50%, does your source channel have more than 50% balance on your side considering the amount that will be deducted after successful rebalance? If you want to use it no matter what you should specify `--pfrom=100` (or any target above 50) and `--allow-unbalance-from`.

I'm sure I'm missing something... heres an example.

config file is:

{
 "macaroon_dir": "/home/regolancer/.lnd/data/chain/bitcoin/mainnet/",
 "macaroon_filename": "admin.macaroon",
 "network": "mainnet",
 "tlscert": "/home/regolancer/.lnd/tls.cert",
 "econ_ratio": 0.2,
 "amount": 10000,
 "min_amount": 5000,
 "probe_steps": 5,
 "pfrom": 10,
 "pto": 30,
 "stat": "stats.csv",
 "lost_profit": true,
 "exclude_channels_in": [
 ],
 "exclude_channels_out": [
 ],
 "exclude_channels": [
 ],
 "exclude_nodes": [
 ]
}

$ go/bin/regolancer -f /home/regolancer/config.json

2022/10/02 06:53:59 Attempt #2, amount: 10000 (max fee: 0)
Total fee: 1
826396237984169984 [allyourbankarebelongtous|75ch|2.96,267,124sat|035fed4182fbd0725264f8a0018cabb6b25514dd231291162ac8dd63afb278e9e8]
825335209304981506 1000 [Xolotl ⚡ LND|47ch|3.82,000,000sat|033b277b17cf7c70fd4de5cbe8dcaeda0cd63d44fcd680f82f76dcac2ebad10c2f]
825424269808435201 10 [Stone Of Jordan|135ch|13.04,996,386sat|02bce4f7ae5b2d51c18575b3f277e296d9df800a54d749d7a3145c9e40237e4011]
815450599751221249 0 [zero fee routing | CLN|1387ch|84.74,988,554sat|038fe1bd966b5cb0545963490c631eaa1924e2c4c0ea4e7dcb5d4582a1e7f2f1a5]
811015169933639681 0 [Thrash.at|134ch|3.77,192,869sat|03ac61c971d146787a036f75e80a9fbede238a75d0c396f1fe996def00f0ac5dbe]
816899756183846912 251 [Milky*Cilia|230ch|25.15,165,870sat|022a03c83e94ab037a64dd71e54f1796db185f21b1d88ceea5486a274ec257e995]

2022/10/02 06:54:13 Success! Paid 1 in fees

... telegram bot reports I paid 126 ppm to rebalance from allyourbanks (currently I charge 50ppm) to Thrash.at (currently I charge 30ppm)

Yeah, that looks wrong. Do you use the latest version from master? #5 was fixed, when the max fee becomes negative lnd simply ignores this restriction and uses whatever route it finds. In your case it says 0 but if the actual fee is less than 1 sat (and more than -1 sat) it could've been rounded up to zero.

Got it.. Not as familiar w the workings of github, branches/etc… followed this guide with exception of changing version to 1.2.0

 URL

On Sun, Oct 2, 2022 at 7:19 AM, rkfg ***@***.***> wrote:

Yep, could be confusing. Maybe it's better to install with `go install github.com/rkfg/regolancer@master` instead of `@latest`. I'm not good at versioning admittedly 😅. Btw cool guide, I didn't expect someone to write it for my software! Feels extremely rewarding, thanks!

Will give it a try - satsHive did the guide for raspibolt. Thank you

On Sun, Oct 2, 2022 at 7:27 AM, rkfg ***@***.***> wrote:

@master worked! Thank you

Using your suggestions above I also tried -pfrom and --allow-unbalance-from in an attempt to force a rebalance with a max ppm as:

$ go/bin/regolancer -f /home/regolancer/config.json pfrom=100 --allow-unbalance-from --fee-limit-ppm=25 --from=828274203871412225

however it still says no source channels exist... that particular channel has about 50% outbound currently. Am I missing any other required flags/attributes? Thank again

Disregard .... needed --pfrom=100

It works; crazy fast thank you! Will continue experimenting with this

Glad it worked, I also added displaying msat fees, hopefully everywhere they're shown. They look like `0.350` and such, I tried `350msat` but it was lowkey ugly and confusing. And unknown flags should result in descriptive errors now.

Take "lost profits" from source channels into consideration for picking a route
Rebalance-lnd's biggest strength coming from the economical viable computation whether a source is the right source or not.
I just tried a rebalance with --pfrom and --pto, and it picked a rather expensive source, to pull a certainly cheaper target.

Aware that I can exclude the channel or the node, but is it feasible to implement the profitability computation to mark sources only if the cost + lost profit is < than the possible profit of a target?

This can be added as an optional parameter, yes. I never found it useful personally because I know which channels are sinks and can simply exclude them from the sources (and they usually have less than 50% outbound). The rest rarely move themselves so their fees are more like random rewards I don't count on much. Setting zero fee on those channels doesn't help moving them at all so I just leave it small.


Question: [ServerErrors][TypeScript] 5.0.0-dev.20230206?

Probably all related:

* URL
* URL
* URL
* URL
* URL
* URL
* URL
* URL

I'll try closing these and we'll revisit if they pop back up.

[ServerErrors][TypeScript] 5.0.0-dev.20230206
The following errors were reported by 5.0.0-dev.20230206
Pipeline that generated this bug
Logs for the pipeline run
File that generated the pipeline

This run considered 200 popular TS repos from GH (after skipping the top 0).

 Successfully analyzed 187 of 200 visited repos

| Outcome | Count |
|---------|-------|
| Detected interesting changes | 8 |
| Detected no interesting changes | 179 |
| Git clone failed | 1 |
| Unknown failure | 12 |

## Investigation Status
| Repo | Errors | Outcome |
|------|--------|---------|
|angular/angular-cli|1| |
|apache/echarts|1| |
|BuilderIO/qwik|1| |
|GrapesJS/grapesjs|1| |
|mantinedev/mantine|1| |
|nocodb/nocodb|1| |
|palantir/blueprint|1| |
|redwoodjs/redwood|1| |

The `addImportFromExportedSymbol` from grapesjs and nocodb is likely the same, and filed at #52662.

The echarts issue with `getMemberOverrideModifierStatus` and `getTextOfPropertyName` is filed at #52664.

Assertion failure when class member snippet relies on default-exported type
ts
// @filename: other.ts
export default class Other {}

// @filename: base.ts
import Other from "./other";

export class Base {
 foo(): Other {
 throw new Error("");
 }
}

// @filename: derived.ts
import { Base } from "./base";

export class Derived extends Base {
 /*$*/
}

Request completions with class member snippets and snippet completions enabled.

Message: Error processing request. Debug Failure.
Error: Debug Failure.
 at Object.addImportFromExportedSymbol (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:156324:70)
 at /vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:161889:63
 at Array.forEach ( )
 at importSymbols (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:161889:21)
 at createSignatureDeclarationFromSignature (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:161567:25)
 at outputMethod (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:161495:30)
 at Object.addNewNodeForMemberSymbol (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:161474:25)
 at getEntryForMemberCompletion (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:135751:24)
 at createCompletionEntry (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:135603:23)
 at getCompletionEntriesFromSymbols (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:136106:29)
 at completionInfoFromData (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:135415:31)
 at Object.getCompletionsAtPosition (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:135275:36)
 at Object.getCompletionsAtPosition (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:169151:35)
 at IpcIOSession.Session.getCompletions (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:181300:64)
 at Session.handlers.ts.Map.ts.getEntries._a. (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:179973:61)
 at /vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:182034:96
 at IpcIOSession.Session.executeWithRequestId (/vscode/bin/linux-x64/some-id-insider/extensions/node_modules/typescript/lib/tsserver.js:182025:28)


Question: Create a POA request in vets-api?

Will include this in the request endpoint. Blocked until Jon is done building that.

Create a POA request in vets-api
## Background
For users intending to submit a request digitally, the CTA on the `review-and-submit` page will update to "Submit form" (per URL When the user clicks "Submit form" on the frontend, the backend should create a POA request in vets-api. This will allow the request to appear in the Accredited Rep Portal, for a representative to accept/decline.

If the creation fails, the frontend will need to know so that it can show the user an error and give them the opportunity to try re-submitting. (That will be handled in URL

Implementation note:
- We can assume that we'll have approval for pilot (which will be 6-12 months) for the POA request to be in the vets-api database (not CorpDB).

Open questions:
1. What is the expectation (if any) in the VA Forms Library, when a form is submitted? Are there any built-in callbacks or submit hooks that we can pick up?
2. What information should be included in the request?
3. How/where do we create the request, so the ARP can receive it?
4. After the POA Request is created, where do we store the expiration date?
5. After the POA request is created, do we need to store the record ID anywhere in ARM code for future troubleshooting?

## Tasks
- [ ] Create a POA request
- [ ] Pass an error back to the frontend if there is an issue creating the request
- [ ] Unit tests

## Acceptance Criteria
- [ ] When a user clicks "Submit form" on the Review page, a POA request is created in a vets-api database which is then passed to the Accredited Representative Portal for a representative to accept/decline the POA request.
- [ ] When there's an error creating a POA request, let the frontend know so it can serve an error to the user.

Partially blocked on this until ART finalizes their models. There's a stack of inflight work that will significantly change their modeling and that makes it difficult to create requests at this time.

In the meantime, we can make a generic endpoint for submission so that the front end has that integration ready to go. we can put in a temporary way to force errors to surface that to users, and we can test the success email.

Calling out the work related to this, in case we need to reconsider any other approaches once the ARF models are finalized:
1. #99802
2. #99804
3. #99973
4. #99803
5. #101322

First pr is in review. It will need ART and Platform approval to merge

Digital submission email confirmation in VA Notify Staging
## Background
In #99802, users who intend to request POA digitally will have a new "Submit form" CTA on the `review-and-submit` page.

Clicking "Submit form" will create the POA request ( URL and after that request is successfully created:
1. The user will be routed to the `confirmation` page
2. If the user entered an email address for themself (Veteran users only for v2), the user will receive an email notification reiterating the next steps.

This email notification currently exists in VA Notify Staging with the name "Appoint a Representative v2 - Digital Submit Confirm".

## Tasks
- [ ] After a POA request is successfully created, engage VA Notify for the "Appoint a Representative v2 - Digital Submit Confirm" email.
- [ ] Work with @oddball-lindsay to adjust variables in the email template, as needed.
- [ ] Confirm everything is working as expected in VA Notify Staging.

## Acceptance Criteria
- [ ] The Appoint v2 experience is setup to send an email notification to any users who request POA digitally.
- [ ] The VA Notify template is rendering as expected, including variable content and is ready to be promoted to Production.

Now that the submission endpoint is done I can continue working on the data model for the email and can put the code that calls it in that new endpoint. That calling code will probably be moved elsewhere eventually.

The data object that takes the PDF/digital form submission and extracts the info used in the email template is done. I need to write some tests for it and it'll be ready to go.

@opticbob confirming I've removed the times from the email template:

Image

This is still in team review. Platform has reminded me that they can't review it until it's been team reviewed.

The PR for this is team and Platform reviewed and ready to merge. I haven't merged it yet because I can't figure out how to add the staging template id to the vsp-infra-application-manifests repo. The staging file I added to last time no longer contains those values and I can't find it in the repo. I confirmed that the email is still sending just fine from staging.

I've asked the VA Notify team for assistance, details on slack.

The code for sending the email is done, I haven't added the template id to the manifests repo where that value can be used from within `vets-api`. The PR to do that is waiting on feedback from Platform.

Platform has responded, I've updated the PR and that is back in front of them to review.