Filters middleware

Add Message Filter Chain System
Overview
This PR introduces a middleware-based filter chain system for message processing, allowing custom filters to be created, managed, and executed before messages are sent to the LLM. This architectural change enables message transformation, short-circuiting, and custom processing logic to be injected into the chat flow.
Key Changes
1. Filter System Architecture

Added new filter chain execution system with middleware pattern
Implemented filter management UI in Settings panel
Added persistent storage for filters in IndexedDB
Created drag-and-drop interface for filter reordering
Added code editor for filter creation/editing
Implemented filter execution pipeline in chat flow

2. Database Updates

Migrated to IndexedDB Provider pattern for better DB management
Added new 'filters' object store in IndexedDB
Increased database version to 2 to accommodate new schema
Added proper database initialization and cleanup

3. UI Enhancements

Added new "Middlewares" tab in Settings panel
Created FilterCard component for filter management
Implemented FilterEditor with CodeMirror integration
Added drag-and-drop functionality for filter reordering
Created modal interface for filter creation/editing

4. Chat System Integration

Modified chat flow to execute filter chain before LLM requests
Added support for filter-based message transformation
Implemented short-circuit capability for filters
Added filter context object with access to chat state

5. Component Architecture

Created new FilterTab, FilterList, FilterCard, and FilterEditor components
Implemented useFilters hook for filter management
Added IndexedDBProvider for better database context management
Moved shared types to dedicated type files

Technical Details
Filter Chain Execution

Filters are executed in order based on their position
Each filter can:

Transform the message and continue the chain
Short-circuit with a direct response
Pass through without modifications

Filters have access to:

Current message context
File system state
System prompt
Chat history

Database Schema
New filters object store with structure:
interface FilterItem {
  id: number;
  name: string;
  order: number;
  content: string;
}

Testing

Tested filter creation and editing
Verified filter ordering functionality
Tested filter execution in chat flow
Verified database migrations
Tested filter chain short-circuiting

Migration Impact

Requires database version bump to 2
No breaking changes for existing chat functionality
All filter features are additive
Existing messages and chat history remain unchanged

Future Improvements

Add filter templates and presets
Implement filter import/export
Add filter execution logging
Create filter debugging tools
Add filter execution metrics

Preview
https://github.com/user-attachments/assets/503ee203-66f9-4f2e-af9b-007d75ccb7aa

@coleam00  #578 , this entire PR can be done by only using a filter
here is the code
import ignore from<EMAIL_ADDRESS>
function simplifyBoltActions(input) {
  // Using regex to match boltAction tags that have type="file"
  const regex = /(<boltAction[^>]*type="file"[^>]*>)([\s\S]*?)(<\/boltAction>)/g;

  // Replace each matching occurrence
  return input.replace(regex, (_0, openingTag, _2, closingTag) => {
    return `${openingTag}\n          ...\n        ${closingTag}`;
  });
}

// Common patterns to ignore, similar to .gitignore
const IGNORE_PATTERNS = [
  'node_modules/**',
  '.git/**',
  'dist/**',
  'build/**',
  '.next/**',
  'coverage/**',
  '.cache/**',
  '.vscode/**',
  '.idea/**',
  '**/*.log',
  '**/.DS_Store',
  '**/npm-debug.log*',
  '**/yarn-debug.log*',
  '**/yarn-error.log*',
  '**/*lock.json',
  '**/*lock.yml',
];

async function createFilesContext(files ) {
	// let ignore=await<EMAIL_ADDRESS>	const ig = ignore().add(IGNORE_PATTERNS);

  let filePaths = Object.keys(files);
  filePaths = filePaths.filter((x) => {
    const relPath = x.replace('/home/project/', '');
    return !ig.ignores(relPath);
  });
  console.log(filePaths);

  const fileContexts = filePaths
    .filter((x) => files[x] && files[x].type == 'file')
    .map((path) => {
      const dirent = files[path];

      if (!dirent || dirent.type == 'folder') {
        return '';
      }

      const codeWithLinesNumbers = dirent.content
        .split('\n')
        .map((v, i) => `${i + 1}|${v}`)
        .join('\n');

      return `<file path="${path}">\n${codeWithLinesNumbers}\n</file>`;
    });

  return `Below are the code files present in the webcontainer:\ncode format:\n<line number>|<line content>\n <codebase>${fileContexts.join('\n\n')}\n\n</codebase>`;
}

function  processMessages(messages){
	return messages.map((message) => {
    if (message.role == 'assistant') {
      let content = message.content;
      content = simplifyBoltActions(content);

      return { ...message, content };
    }

    return message;
  });
}

export async function filter(filterReqObj) {
	console.log(filterReqObj)
	filterReqObj.messages=processMessages(filterReqObj.messages)
	let codeContext = await createFilesContext(filterReqObj.files);
	filterReqObj.systemPrompt=`${filterReqObj.systemPrompt}\n\n ${codeContext}`
	return; // Continue to next middleware
}

@thecodacus  Works great, looks, great

Dear @thecodacus ,
thanks for sharing this! I understand your motivation for this is to be able to better tune the interaction with the LLM.
I agree that this is currently cumbersome. Plus: lots of magic is within the prompt and passing all files as context is probably not future proof.
This PR empowers the user with some flow-based programming to adapt that, right?
Although I am a big fan of flow-based programming, I have two doubts:

I am not sure that we should surface this to the user. It will be very powerful to change / improve but also destroy the interaction with the LLM (not only speaking about meaows ;) ) . I'd expect the workbench itself to reasonably pre-postprocess messages back-and-forth to the LLM and not pass this burden to the user.
Also, DevEx in such a brwoser-dialogue is limited, compared to what we have in an IDE (code-completion, syntax validation and finally debugging (although the browser should allow that once I figured out where to put the breakpoint))
=> I'd love to see pipelining of LLM-interaction in the codebase, but rather not on the UI.
I see a functional overlap to agents / tools: Also, an agent would be able to orchestrate interaction with the LLM. As you have also architected the tools-infrastructure-proposal (#302): How would this fit together?

Hope you don't regret having tagged me as I question the bigger picture!
Cheers, Oliver

Hi @mrsimpson , I get what you are saying. hopefully my explanation below can answers these questions

I am not sure that we should surface this to the user. It will be very powerful to change / improve but also destroy the interaction with the LLM (not only speaking about meaows ;) ) . I'd expect the workbench itself to reasonably pre-postprocess messages back-and-forth to the LLM and not pass this burden to the user.

you can think of this as giving users some programatic power over the tool without explicitly changing the core code of the tool. this opens up door to creating unlimited future possibilities. and the intention is not to put the burden on the user but giving some power and freedom to explore and experiment, definitely creating such things are for the power users.
Plus this is totally optional thing for the user

I see a functional overlap to agents / tools: Also, an agent would be able to orchestrate interaction with the LLM. As you have also architected the tools-infrastructure-proposal (https://github.com/coleam00/bolt.new-any-llm/pull/302): How would this fit together?

these two are independent features, and can be used in parallel. we will have our own agent framework natively integrated to the codebase. I am not saying we should develop new features using filters/middleware in future.

DevEx in such a brwoser-dialogue is limited, compared to what we have in an IDE (code-completion, syntax validation and finally debugging (although the browser should allow that once I figured out where to put the breakpoint))
=> I'd love to see pipelining of LLM-interaction in the codebase, but rather not on the UI.

the browser dialog is actually the same component that bolt ide is using, it can be easily extended to have code completion and syntax validation.

=> I'd love to see pipelining of LLM-interaction in the codebase, but rather not on the UI.

community can build filters and share it with others to use. we will be doing our own official developments in the codebase that will not change, but will not be doing everything tailored to specific user's need.
so this feature can stop, US being the bottleneck for the community
the ultimate plan is to run everything on browser and not have any server component. then this can evolve into plugin system and the whole community can start building and share them in a way that you can compare it with wordpress plugins system.
I like to have an open discussion, If you have any other contrary thought please share I am open to discussion. I like to understand opposite views

@thecodacus thanks for confirmation, I absolutely understand the intention of this PR.
Still, I'm worried about adding such a feature to the app at its current stage: Providing a UI which allows the user to inject code into the apps runtime is an extreme way of customization. With great power comes great responsibility – and usually a huge burden of maintenance.
Is this really a feature that users requested? I'd expect that the consumers of such a feature are developers who can anyway fork and run the app themselves.
Why not just provide an API which developers who want to customize bolt.diy can implement when forking it? Then, it would not be a feature which results in issues on bolt.diy when e. g. erroneous code has been entered into the dialog. If it was "only" an API, customizers would also benefit from their IDEs syntax validation etc.

the ultimate plan is to run everything on browser and not have any server component.

You mean on the whole app? I believe we'll always have a server component due to CORS and the need to hide credentials from the client. Or did you refer to a particular aspect of the app that should be server-free?

Another idea as a compromise: WDYT about providing developer documentation on how to utilize a "message-preparation-pipeline" API? If we surfaced it in documentation, this might give us best of both worlds: Us not being the bottleneck + community engagement. Plus: We could implement a scraper on the forks of bolt.diy and see who implemented the API ;)

@coleam00 since you are the most product-own-er-alike person on this project ;) I'd like to read your opinions on where and when to evolve the app. If it was – for whatever reason – an urgent thing to give such powers to the end-user, I'd look at this PR differently, of course!

I think we do need context management middleware that steps in somewhere before messages are sent to AI, gets whole chat conversation, access to workbench files and prompts.
And then can decide of what to remove and what to add.
But I was thinking of it more like plugins, not code that is written and copy pasted by users.
That is indeed not a feature for users.
I still need to take a look at filter part itself.
But way you add filters seems wrong.
It rather feels like we need to have collection of filters with parameters user can set.
And one of the filters is developer filter that does what you show here.
But most users will not use it.

There are few topics in this thread like making Bolt rely less on server, its big initiative that may be desirable, I agree that it may not be fully possible. Main reason I am interested in that is giving access to LM Studio and Ollama from browser.
Making other providers work fully from client may not work for all of the providers due to cors as @mrsimpson said.
As for what users are asking for, they are asking for better context management and token usage, which is a complex thing that is often opinionated so its best to have middleware system for it with ability to try different combinations and strategies depending on the model too.

BTW for future upkeep if we decide to refactor how filters work and users have code written then it will break.
If code is not in repo it will be breaking with updates.
That is one more argument against this kind of user scripting in our case.

BTW for future upkeep if we decide to refactor how filters work and users have code written then it will break.
If code is not in repo it will be breaking with updates.
That is one more argument against this kind of user scripting in our case.

I understand that, but that is same for any filter/plugin systems, the whole purpose of creating any external plugin is thats it will not be part of the repo. it can  break with updates, check the wordpress plugins. they only work for certain version of the wordpress.
and for any issues related to plugins functionalities its not the core repo maintainer's responsibility to resolve that its the plugin developer's responsibility.

But I was thinking of it more like plugins, not code that is written and copy pasted by users.
That is indeed not a feature for users.

ultimately a plugin is just a code written by a person and its injected into the system where the code tool has exposed some apis. and this is also an api exposed from the tool that a developer can use to inject some logic, I am failing to understand the differences
Yes, we can hide the editor window and only use  import and export button to load a filter.. and then that filter can be written in an ide and compiled into a single file using bundler. then loaded in to the tool.  but thats just a design choice not a architectural change, its still a code injected at runtime which uses the same apis that exposed now with the browser editor.

Why not just provide an API which developers who want to customize bolt.diy can implement when forking it? Then, it would not be a feature which results in issues on bolt.diy when e. g. erroneous code has been entered into the dialog. If it was "only" an API, customizers would also benefit from their IDEs syntax validation etc.

Like I said I dont like the idea of PRs coming in for every plugin people develop and I don't like the idea of being the gate keeper for that.
plugins  / filters should not be part of the main Repo, thats the whole idea of this proposal.
And about using IDE's yes you can still do that. like i mentioned above its just closing the browser editor and making it import only feature
what are you thoughts on this ??

BTW for future upkeep if we decide to refactor how filters work and users have code written then it will break. If code is not in repo it will be breaking with updates. That is one more argument against this kind of user scripting in our case.

It will still work if we have to keep the api same.
And if we totally change the api and how its integrates with the tool then we have to deprecate filters and add something else in place of that. thats the proper way to do it.

here is what inspired this PR
https://github.com/user-attachments/assets/1231e590-77c9-416e-b4ca-811fa0af59c6

does this makes more sense, assuming I disable the edit button ?
https://github.com/user-attachments/assets/d19b2ea0-0bef-4e96-8006-faf4d911d18f

I will take another look tomorrow.
But was thinking about your replies.
I think we should keep plugins inside of repo for now.
I makes sense to get them out when we stabilize API
USually at early stages it changes a lot
When it stabelizes and we can guarantee no changes to API more friquent than say 6-12 months than we can move plugins out.
So for now I am for having them in so we can work on it in more centralized and breaking changes way.

sure, makes sense.. I will keep updating this to keep up with the main.
meanwhile I will extract the database context provider from this PR and put it into a separate PR as that is a refactoring effort and does not need to be part of this PR

@thecodacus wdyt about moving all the filters mechanism into a function like prepareMessages which is invoked prior to calling the llm?

I dont think that a good idea, because i plan to expose lots of apis in this and server has very little access to the tool apart from the thing that is sent to it, for example I can expose the webcontainer apis if want which is not possible in server side.
and again is its a pluggable thing that can be injected then the actual code will reside on the Indexdb, I don't like the idea of posting all the filter code back and forth to server with api calls and make the payload huge for every llm calls

All three of you guys @thecodacus / @mrsimpson / @wonderwhy-er have put so much thought into this and I seriously appreciate it! So sorry this discussion someone slipped through my notifications even though I was pinged multiple times. I really try hard to keep up with these so just know that if you ping me generally I will be right on top of it!
Looking at this discussion, I think both sides make good points, but here's my take:
Overall, the idea of having a middleware system for processing messages makes a lot of sense and I love the work here. @thecodacus, you clearly put a lot of thought into making it flexible and powerful and this is going to lay an incredible foundation for our plugin system no matter how we end up implementing this as a "v1".
On the other hand I do completely get @mrsimpson and @wonderwhy-er 's concerns about exposing code editing directly in the UI because of how uncontrolled it is and how maintenance heavy it could become. I also agree that it'll take some time for us to truly figure out how to use this feature to solve core problems our userbase has right now.
I'd suggest starting simpler:

Build the middleware system as something more internal to start
Keep the initial filters in the main repo until patterns emerge
Add import/export functionality rather than in-browser editing
Focus on solving common use cases first (like tweaking the system prompt in experimental ways)

This gives us the flexibility to expand it into a full plugin system later, but with more guardrails and stability. I still love to idea of getting to the Open WebUI functions-like feature as you called out as inspiration, Anirban! And I agree that we don't want these to be served from the server.
What do you all think about that approach? It seems like it would address the core needs while avoiding some of the risks that were raised in the discussion.


Support “imageUrl”: “https://example.com/altrss/image.png”, alongside episode url

Support an (optional) imageUrl tag, for an unified way for podcasts hosts and clients that support this namespace, to embed the URL for a square image displayed for the referenced podcast, so that even this episode title image could be federated accross Podcastindex compliant platforms.
This could be a field next among the url, or the episode title fields.

If this is a suggestion for the Podcast Index API, I love this idea.
(What would be amazing, but fully understand why it might be a bad idea, is for the image to also be pulled out of the MP3/AAC file if it isn’t present in the RSS feed, and populated into the API. That would be intensely bandwidth-heavy, and probably the worst idea in the world, though potentially possible to use podping and a set of volunteer servers running this as a distributed service).

I’m not sure I understand what’s being asked for. Can you try again to explain it a bit differently?  Apologies if I’m being dense.

I’m not sure I understand what’s being asked for. Can you try again to explain it a bit differently? Apologies if I’m being dense.
In the specification, there should also be a unified way of where to find and to source thumbnail images for episodes from (by podcast clients), such as specyfying a “imageUrl” tag, that would recognisably always be followed by a direct link to the thumbnail .png/.jpg image file.

The API returns an image URL for each episode anyway, as seen here: https://podcastindex-org.github.io/docs-api/#get-/episodes/byitunesid
An image URL is given in standard RSS, for episodes.
So I'm confused as to what is being asked for here too.


Unlock withoutOverlapping method when the process receiving signal

Task Scheduling: Unlock withoutOverlapping method when the process receiving signal
With this change I try unlock withoutOverlapping method when the process receiving signal, for example kill -9 (OOM killed, ...)
This PR add the catch RuntimeException when the schedule runs. This catch unlock mutex in withOverlapping method when this exception throws.
This Exception is throw for symfony/process
Additionally this PR add these task hook:

fail; specify code to be executed when the scheduled task fails (same before, after)
pingFail; the scheduler can automatically ping a given URL when task fails

How would the php engine execute any code all if it was killed by either a SIGKILL signal or killed by the out-of-of-memory killer?

@sisve Really this work because the signal kill is received by subprocess. https://symfony.com/doc/current/components/process.html#running-processes-asynchronously
Schedule is the parent and run a new subProcess (the command) In this case, the schedule received the signal respect the subprocess (command) and then the parent can work.
Normally the command load more  resource of system, example: export, ...
But we get other signal for subprocess, example kill -15 if the system is reboot.

Ah, that would explain your initial description. I was thinking of, what could then be described as, the "host script".

I am closing this pull request because it lacks sufficient explanation, tests, or both. It is difficult for us to merge pull requests without these things because the change may introduce breaking changes to the framework.
Feel free to re-submit your change with a thorough explanation of the feature and tests - integration tests are preferred over unit tests. Please include it's benefit to end users; the reasons it does not break any existing features; how it makes building web applications easier, etc.
Thanks!


README at the root of the flutter repository contains dead links to images.

As of https://github.com/flutter/flutter/commit/65cd84b58885fb78bd2d27f60fa7209bedf5be25, the README.md at the root of the repository contains images in the website repository that seem to have moved. These links are:

https://github.com/flutter/website/blob/main/src/assets/images/docs/homepage/reflectly-hero-600px.png?raw=true
https://github.com/flutter/website/blob/main/src/assets/images/docs/homepage/dart-diagram-small.png?raw=true

These images must be moved into the Flutter repository itself so changes in an unrelated repo don't cause dead links.

This has been fixed.


Updated Readme.md

I am developer from eGHL. I can see that someone else 'XU Ding' already added omnipay integration with eGHL. What do you suggest about duplication?

We suggest collaboration  ;)
ping @dilab

@barryvdh @jhumayun sure. how can I help?


Optional ROOT_PATH parameter

First of all, thank you for the great plugin.
Could you please make it possible to store source and resulting files at the root of storage (bucket)?
Without the need to define *_STORAGE_ROOT_PATH
http://minio:9000/img-cache/rs/default/unsafe/300x400/yezhik.jpg
The `/rs` needs to be removed

And I have another question, what /default/ stands for in the path of the resulting file?

@beeyev we've addressed the /default/ part in this issue: https://github.com/thumbor/thumbor-aws/issues/16

@beeyev is there an error when you set *_STORAGE_ROOT_PATH to an empty string?

For example, if I set AWS_RESULT_STORAGE_ROOT_PATH=''
The path will contain double slashes
http://minio:9000/img-cache//unsafe/300x400/yezhik.jpg

I cannot replicate this behavior on the tests, do you think you can create a PR to address it?

You can find this path with doubled slashes in logs if you enable debug mode.


Async Execution (project scheduling)

Pull Request Description
:warning: This is currently blocked waiting for the corresponding backend functionality.

Frontend part of https://github.com/enso-org/cloud-v2/issues/1392

New modal to schedule project executions
New tab in asset right menu that lists project executions
Choose repeat interval (hourly, daily, weekly, monthly)
Choose parallel mode to control behavior when multiple executions are scheduled at the same time (ignore new execution if old one is not finished, cancel old execution, run both executions at the same time)
Select and display maximum execution time
"Use Current Version" button
Paused ("disabled") schedules

Important Notes
None
Screenshots
"New Schedule" dialog

List of execution schedules:

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[x] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
TypeScript,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
[ ] Unit tests have been written where possible.

@indiv0 note that if (when?) you do end up testing this PR that this PR mocks out the endpoints, the actual impls need to be uncommented (and the mocks removed) to test with an actual backend

Eventhough it's blocked by the backend, nothing's stopping us to merge it behind a flag

Lets simplify things and inspire with google calendar scheduler (without custom):

Description:

Header: Schedule task
First row: Start date with date, time, timezone selectors
2nd row: repetition selector: Does not repeat (default), Hourly, Daily, 30th in Month, Last Sunday in Month (last 2 based on selected date)
Hourly: select first / last hour (range)
Daily: Select which days of the week should run
30th in Month, Last Sunday in Month: Choose which months,


Reconnect Retry

[x] Server Pool

A server list pool is maintained. There is a complete implementation in Java for reference.

[x] Max Retries: How many times each server in the pool should be tried.
[x] Jitter
[ ] Tls Jitter
[ ] Server List Callback

When connecting, server returns list of URLs to other servers in the cluster.
Client should store them and use when reconnecting, but users need to be able to disable this option, meaning that client ignores the returned additional URLs and use only the ones passed by a the user.

[ ] Ignore Discovered Urls:

Clients can ignore discovered servers instead using just bootstrap.

Already part of the released alpha client.

There is a full specification for reconnect behavior. In my head right now, but partially started in this ADR https://github.com/nats-io/nats-architecture-and-design/pull/202. I will work on it.
@mtmk Please see me in the meantime to discuss.

This is mostly implemented. We will revisit.

@scottf, I Updated the todo above. Let me know if I missed/messed something.


add UI for json editor

imho, better handling this http://localhost:8089/config/json to start page, just like the reset/stats or swarm


Whether its possible to seperate the flow of identity server 4 based on each clients grant types

Our existing application (its an internal application which allows users of a particular AD)
Web client 1
Web api
Identity server 4 (which usings Ldap to to fetch the current AD user and assign respective roles based on the AD permission level which is set in the DB )
Problem :
Web client 2
Web api
Identity server 4 (authenticate user by using resource owner password grant )
What we are trying to achieve is to extend our web api to an external website , whose login(username and password) are available in our database. So we tried using the resource owner password grant by using resourceownervalidator and profile service. it worked , but its breaking the existing flow(the flow which was setup for web client 1).

I think you have access to the client ID in the validator. So you can branch your logic based on that.


[docs] fix Expansion Panels demo of zh doc

[x] I have followed (at least) the PR section of the contributing guide.

Thanks for the contribution. We normally manage translations here, and I have found, and hopefully fixed, the errant 'code' translation.
However the wrapping in <p> tags is slightly concerning. That doesn't show up in CrowdIn, so your PR may be the only way to fix it. We have github sync disabled at the moment while waiting for a bug fix from CrowdIn, so I'm putting the PR on hold until that's fixed.

I did a second pass on the <code> issue. I have replaced it with a backtick `.
The list issue is well summarized in https://talk.commonmark.org/t/blank-lines-before-lists-revisited/1990. I have change the syntax to make crowding happy. It's most likely an issue with their engine.

@GFwer Thank you for reporting these issues!


Nested documents a.k.a. Block Join

Support indexing and searching nested documents.
For indexing see https://cwiki.apache.org/confluence/display/solr/Uploading+Data+with+Index+Handlers?focusedCommentId=48792150#UploadingDatawithIndexHandlers-NestedChildDocuments
For querying the nested documents, see https://cwiki.apache.org/confluence/display/solr/Other+Parsers#OtherParsers-BlockJoinQueryParsers

Current issue has been closed as part of cleanup process, which is tracked in https://github.com/SolrNet/SolrNet/issues/338.
Please reopen if needed, hopefully helping bringing up to date with current code.


Support for Scala 2.12

Could you please release a version for Scala 2.12?
Thanks!
Daniela

Please, have a look at PR https://github.com/underscoreio/slickless/pull/13.
This is blocking us from upgrading to Scala 2.12, so it would be great if this could be merged and released as soon as possible.

Thank you @DanielaSfregola - that's now on its way to Sonatype. Give it a couple of hours and hopefully it'll be avalable.


No-op if engineedition is 6 or 11 due to lack of support for ASSEMBLYPROPERTY function

fixes #2588
https://learn.microsoft.com/sql/t-sql/functions/assemblyproperty-transact-sql

@David-Engel  @JRahnama  can we get a review for this. Seems like the API is busted with Fabric DW


TXT awverify are not working when migrating from an active Azure website

We have tried to follow the steps in this page without any success.
We had to perform a migration between Appservices hosted in different subscriptions and webspaces.
The migration completed correctly after adding both the TXT awverify.{subdomain} record and the TXT record asuid.{subdomain} with the key found in the Azure portal.
If this is how it is supposed to work, it is missing from this documentation page.

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

ID: 56baff6e-3653-f1a5-1c9b-dd4d372e2291
Version Independent ID: e44e3b63-6f49-ef86-0607-2c1a71a86bd0
Content: Migrate an active DNS name - Azure App Service
Content Source: articles/app-service/manage-custom-dns-migrate-domain.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin

@Fax Thanks for the feedback! We are currently investigating and will update you shortly.

@Fax Thanks for bringing this to our attention. Your feedback has been shared with the content owner for further review.

Fixed in https://github.com/MicrosoftDocs/azure-docs-pr/pull/126694 which will be published today. #please-close


After a crash during unit testing, the app cannot start up

On hardware, after the app crashes during unit testing, the app cannot start up.

Delete the app.
Install a new copy and run unit tests from Xcode.
App crashes (see #3662).
Restart app.
App is frozen at start up screen.

@hboon @oa-s @colourfreak I've tracked down the problem to AppCoordinator.swift:86
        if isRunningTests() {
            startImpl()
        } else {
            DispatchQueue.main.async {
                let succeeded = self.startImpl()
                if succeeded {
                    return
                } else {
                    self.retryStart()
                }
            }
        }

where in AppCoordinator.swift:120
    @discardableResult private func startImpl() -> Bool {
        if MigrationInitializer.hasRealmDatabasesForWallet && !keystore.hasWallets && !isRunningTests() {
            return false
        }

The functions keeps returning false because the RealmDatabase exists but the keyStore has no wallets. This keeps the app in an infinite loop in AppCoordinator.swift:107
    private func retryStart() {
        DispatchQueue.main.asyncAfter(deadline: .now() + 0.5) {
            let succeeded = self.startImpl()
            if succeeded {
                return
            } else {
                self.retryStart()
            }
        }
    }

Once I can verify @colourfreak 's problem has the same cause, we can fix it.

@hboon @oa-s I would recommend a 15 second timer that will break this loop and asks if the user wants to reinitialise/reinstall the app. A second recommendation would be to store the wallet data in the secure user keychain as a back up and ask the user if they wish to reload from the keychain instead of reinitialising.

@eviltofu Thanks. Let me check this out.

Ok it's not the switching wallet rapidly bug. I was able to restart the app when I had a crash due to the switching wallet bug. #3657

@oa-s would you help to check this too? Thanks :)

Yep, i was able to reproduce it, the problem is that after passing tests we got the list of created realm dbs and as UsersDefaults are empty that is why it stucks.

The app crashes due to error:
AlphaWalletTests/EtherKeystoreTests.swift:184: Fatal error: 'try!' expression unexpectedly raised an error: AlphaWallet.KeystoreError.accountMayNeedImportingAgainOrEnablePasscode
2022-01-13 17:19:17.750579+0200 AlphaWallet[20925:3738079] AlphaWalletTests/EtherKeystoreTests.swift:184: Fatal error: 'try!' expression unexpectedly raised an error: AlphaWallet.KeystoreError.accountMayNeedImportingAgainOrEnablePasscode

@oa-s can you create a PR? Careful with Realm databases and user keys in production.

@hboon @oa-s My suggestion now is to have separate name spaces/folders for testing. This way we won't have to modify the start up code. The realm database could have a new folder just for testing. The Config user defaults could have a prefix tests- added to all the keys.

@eviltofu @hboon Yep, that is what the pr does for this issue. We creating a new folder for realm files during testing. In cache directory we create wallets folder, with realm files, even if the app is crashing we drop folders content on next launch, so this issue shouldn't appear.


Admin panel is not reachable after days of running

I've used the latest version of this, according to the default configuration way in the installation guidelines.
From one day to another the port 81 admin panel is not reachable anymore, not loading no logs.
Can anyone help?

Does a docker restart fix the problem? I run my instances forever without issues.


 The error occurs because there are many input fields with names like ModelName[id][sub][sub Sub Id][key] in the file markup. With the result that the error occurs. Is it possible in the extension to specify what should be processed and what not? Or how to bypass it?

Can you please share page source code with shortcode functionality disabled? I need some data to make a test and reproduce a error

For example, i render this partial content and this error occured.
https://yadi.sk/d/IMFfKnKspAGxUQ
Я тоже скобарь :)

I tested this html on another parser https://github.com/thunderer/Shortcode. It took 37 seconds on my PC just to finish parsing. It is not appropriate for production anyway. For now i dont have enough free time to dive deeper into this topic. But i will investigate this later, thanks for test data


[vscode-graphql-syntax] Text on the same line after #graphql inside a Javascript string is not formatted as a comment

Description:
Observe the following:

Text on the same line after the first #graphql keyword is not formatted as a comment. It can lead to confusion if the code is invalid, but appears valid like this:

Is there an existing issue for this?

[X] I have searched the existing issues

PS: Please fix vscode-syntax-bug.yml issue template. It has the above checkbox only. I had to edit the comment to add the description.

It also seems that using /* GraphiQL */ as a comment before the variable doesn't seem to work.

@ADTC thanks for reporting this bug!
regarding the second comment - you need to use /* GraphQL  (other comment errata here) */ - let me check the new readme hopefully I didn't mess that up!


Create testing namespace and ack-role-account-map ConfigMap before running CARM smoke tests

Issue #368 and follow-up to https://github.com/aws/aws-controllers-k8s/pull/354#discussion_r498401505
Description of changes:

Create testing namespace and ack-role-account-map ConfigMap before running CARM smoke tests

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Having few issues with github secrets ... currently testing https://github.com/marketplace/actions/configure-aws-credentials-action-for-github-actions

Well secrets are not passed to the runner when a workflow is triggered from a forked repository.
^^ https://docs.github.com/en/free-pro-team@latest/actions/reference/encrypted-secrets#using-encrypted-secrets-in-a-workflow


Add BEDROCK_SECURE_ENV env variable

If set to true then all of the secure variables are unset after they are used for configuring WordPress
Disabled by default, so it must be enabled to have any effect
I really like bedrock, but I dislike the idea of using environment variables for secure things. I've seen far too many plugins that allow unrestricted access to the phpinfo() function which would give enough information away for someone to completely takeover a site.

I don't think this is a bad idea. Are there any main plugins that actually include phpinfo() in their code though? I don't recall seeing this. Scary if that's the case though

I just searched through plugins I have on a development system and there are 2 plugins that call it, but those are each calling it from a secure location.  I have definitely seen it exposed before only plugins that I've audited for security issues.

In my opinion, this shouldn't be optional. It should just be done. Also, we can have dotenv do it.

I was originally just going to submit a PR that would just do it, but figured it would get more traction by having it be configurable.
I would have used the dotenv function if it was exposed, but alas it is not exposed because $loader is protected:
    /**
     * The loader instance.
     *
     * @var \Dotenv\Loader|null
     */
    protected $loader;

Ahh, I see. That makes sense. What an odd design, to have a buried "utility method" that can't even be accessed.

The design is a bit odd to me also. It would make sense if \Dotenv\Loader\load() returned a self reference, but it returns an array of all the lines.

Another possibility to doing this instead of adding a function would be to just look using an array
foreach (array( 'DB_NAME', 'DB_USER', ... ) as $key) {
  putenv($key);
  unset($_ENV[$key], $_SERVER[$key]);
}

So far, we like
array_map('putenv', array_keys(get_defined_constants(true)['user']));

But we might wind up doing something different instead. We're gonna keep chatting about it and figure out how to proceed.

Unfortunately putenv doesn't covert it completely, since the keys are also in $_ENV and $_SERVER.

That's fine. We're not concerned about the existence of the keys in the superglobals. We're actually concerned about the environment variables being leaked to child processes and whatnot. Their presence in phpinfo() is inconsequential considering that the the global constants are all there anyway.

Being leaked via phpinfo() was/is my biggest concern, because I have seen plugins give open access to that function, though I was not using Bedrock (or anything that stored important data in env vars) at the time so it wasn't a major deal. I worked with the developers to restrict access to that, but if it's happened before it will happen again.

@jamesgol thanks for bringing this up. It led to us talking about our current usage of Dotenv and we realized that we should move away from it.
The .env file has one main purpose: it keeps your "secrets" in a separate file out of version control. But this comes with downsides: 1) exposes things to phpinfo, and more importantly, 2) exposes the env vars to any child processes.
In our case, there's no actual reason to use real environment variables. We just need a simpler way of setting variables for use in config files.
We're pretty sure we're going to switch to an ini file in the future since PHP has parse_init built-in. Because of this, I'm going to close this PR.


How to get preview windows?

In your video demos, there is a preview window that shows context for many of the results. How do you enable this?

this plugin respect fzf.vim global variables, so you can set
please see: https://github.com/linrongbin16/lin.nvim/blob/a9c7129e44a39755030e40ceb78a0e00116c0072/repo/junegunn/fzf.vim/init.vim#L10

Thank you!


two concurrent versions

The other day I wanted to install ver. 8.4.0 on my ubuntu 18.04 which has per default an older version of qpdf. I did this as usually by downloading the sources, "configure", "make", "make install" without errors (as far as I remember). Initiating qpdf gave an error (which I don't remember), but the error disappeared after reboot.
whereis qpdf results in /usr/bin/qpdf and /usr/local/bin/qpdf.
Both,
/usr/local/bin/qpdf --version
and
/usr/bin/qpdf --version
result in 8.4.0
This wouldn't be serious, however
qpdf --empty --pages file1.pdf file2.pdf file3.pdf -- out.pdf
results in non-continuous page labels. (qpdf is /usr/local/bin/qpdf).
The same command but with /usr/bin/qpdf correctlty results in continuous page labels.
/usr/local/bin/qpdf is from installation date,
/usr/bin/qpdf is one year old.
Is this a bug or did I do something wrong during installation? How can I correct this?
Thanks a lot!

Most likely it's intended behavior. Starting in qpdf 8.3 or 8.4 (Ubuntu 18.04 has 8.2.1), qpdf started preserving page labels from the original files. I guess there may be cases in which this is undesirable. Maybe there should be an option to not do this. Off the top of my head, I can't remember what the behavior is if the labels are not explicit in the files. I'd have to check the code. Please let me know if you'd like further investigation or if you are seeing inconsistent behavior within a single version. I can look at files if you are able to share, or I can send you some commands to generate metadata that you can send (using the new --json mode).

Thanks for the offer. I am fine with using the version of /usr/bin.
However, I find it unusual that two versions that are identical in name (8.4.0) behave differently.
Isn't the parameter "--empty" meant (among others) to reassign continuous page labels and not to use the original page numbers of the individual files?

You're raising an important issue. I have been extremely strict about never breaking compatibility for the library, but I have been less strict about the CLI. I have considered qpdf's behavior up to now of losing page numbering information to be a bug and this to be a fix, but you are pointing out that people may be dependent on the old behavior. What this tells me very strongly is that I need to be quite conservative about changing the behavior, and if I do change the behavior, I need to provide a compatibility flag.
I will mark this as a bug and ensure that the next release includes some way to revert to the behavior of not preserving page labels. When Ubuntu 19.04 comes out in a few days, more users will start getting qpdf 8.4.0 by default, and there won't be an old version in /usr/bin, so this may start affecting more people.

I see what you mean. You think that /usr/bin is the old version. But why does /usr/bin/qpdf --version result in 8.4.0?

Most likely it's picking up the wrong shared library. If you run ldd /usr/bin/qpdf, it will probably show you that it's finding libqpdf.so.whatever in /usr/local/lib. The value of --version comes from the library, but the behavior of preserving page numbers is implemented in the CLI tool itself. Definitely not intuitive, but that's how it works. I didn't realize you were seeing 8.4.0 with /usr/bin/qpdf --version. I should probably do something about that too.

ah, okay, I see.
Thanks a lot for you help and especially for developing qpdf! This is really helpful.
Here, if interesting, the output of ldd:
ldd /usr/bin/qpdf gives (among other lines)
libqpdf.so.21 => /usr/local/lib/libqpdf.so.21 (0x00007f206eaf6000)
ldd /usr/local/bin/qpdf gives (among other lines)
libqpdf.so.21 => /usr/local/lib/libqpdf.so.21 (0x00007ff5d2c76000)

@femifrak Rather than reverting the new behavior of preserving page labels when merging and splitting, I have added a new flag for 8.4.1 called --remove-page-labels which you can use to get the old behavior. I have also updated qpdf --version to notice if the CLI is using a different library version than expected.


Update go version

A new build and release will fix the mac issues users (like me) have been seeing.

LGTM


Update data node operator docs for archival nodes and add information on data compression

Feature overview
In the best interests of the protocol and its users it has been decided that the default retention for data nodes should be set to --archival. This is so that users can access all data from the data nodes as required. There has been concerns regarding the amount of disk space required for running an archival node therefore...
We will update the documentation to make the default set up --archival and also detail (or link to a readme) some instructions on how to use ZFS to lower the perceived barrier to using this compression
Core work

Make archival the default for data node retention
Increase Data Node NetworkHistory.Initialise.MinimumBlockCount default values

Tasks
A checklist of the tasks that are needed to fully document the requested topic.

[ ] update docs where needed to detail --archival as the default set up
[ ] add data node operator recommendations on how to use ZFS

Note that https://github.com/vegaprotocol/vega/issues/9562 made a breaking change to the options such that it is now --mode=[archive|lite|standard] with default archive. So while doing this ticket we can make sure we clean up and references to the old CLI args --archive/--lite.


Link to PEP8 online is broken. Let's change that to a newer one. Option 2: Go to PEP8 online , paste your code and check the format it correctly

Describe the bug
So I am a newbie to opensource project and hoping to find a good opensource project to contribute to
To Reproduce
Steps to reproduce the behavior:

Go to the folder
Click on 'README'
Scroll down to the end of README
See that pep8 online hyperlink

Expected behavior
We should have been redirected to a legit PEP8 online but somehow, the link is broken
Screenshots

Additional context
I think the problem could be solved easily by changing the link to a work pep8online web. Let me know if this issue is legit and clear so that in the future I can contribute more! Really appreciate all your response so that I can learn more!

Hey @bao1311 can you please create a PR, solving the linting issues


HTML elements do not follow a logical structure independent of styling and positioning

They already basically did, but now CSS matches and there may have been some slight adjustments.


Help please... location!?!?

I´m enjoying your apreciated website / app "Sondehub" very much! Just

a small problem: if I start the website with my windows 10 pc or with
the playstore app, I´m asked for permission to set my location, I
allow and averything works well.
If I´m using my android tablet and the app, I´m not asked for give
permission to use my location; same happens, when I use the website
with a smart tv; the pop up box with asking to allow / give my
location, does not appear an so my own location is nut registered?!?!?
What can I do to use your amazing app / website with tablet and smart
tv browser, included the own location set up???
Cheers
Norbert

You're going to have to figure out how to enable location services on whatever platform you are accessing SondeHub is on, we can't help with this.
Just remember that location services just puts the 'blue person' on the map, it doesn't do much else.


Z-Wave JS driver regression causing device misconfiguration

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?
YES, BUT a Home Assistant developer has told me to come here
Is your problem within Z-Wave JS UI (formerly ZwaveJS2MQTT)?
NO, my problem is NOT within Z-Wave JS UI
Checklist

[X] I have checked the troubleshooting section and my problem is not described there.

[X] I have read the changelog and my problem was not mentioned there.

Describe the bug
What causes the bug?
Adding or re-interviewing a device causes the driver to misconfigure the endpoint for receiving messages.
What do you observe?
My z-wave thermostat, which was previously working perfectly in Home Assistant, no longer reports the correct temperature, or any changes made from the thermostat touchpad after a recent update.  Sending commands such as setpoint changes or HVAC mode changes from the HA web UI DO correctly execute on the thermostat, so HA->thermostat communications are working correctly.  It is only the thermostat->HA communications that are not working.
What did you expect to happen?
I expect Home Assistant to properly display the current temperature as reported by my thermostat, as well as other information such as active/idle status, or setpoint changes made using the thermostat touchpad.
Steps to reproduce the behavior:

Re-interview a device that was previously working
The device no longer functions properly
Logs show that the device is configured to listen on a different endpoint than it is actually receiving messages on

Device information
Manufacturer: Radio Thermostat
Model name: CT32
Node ID in your network: 12
How are you using node-zwave-js?

[ ] zwave-js-ui (formerly zwavejs2mqtt) Docker image (latest)
[ ] zwave-js-ui (formerly zwavejs2mqtt) Docker image (dev)
[ ] zwave-js-ui (formerly zwavejs2mqtt) Docker manually built (please specify branches)
[ ] ioBroker.zwave2 adapter (please specify version)
[X] HomeAssistant zwave_js integration  (please specify version)
[ ] pkg
[ ] node-red-contrib-zwave-js (please specify version, double click node to find out)
[ ] Manually built from GitHub (please specify branch)
[ ] Other (please describe)

Which branches or versions?
Driver Version: 10.23.2
Server Version: 1.28.0
Did you change anything?
yes (please describe)
If yes, what did you change?
I updated Home Assistant to the latest version, along with the Z-Wave integration.  At the same time, I also needed to reset my thermostat, which required me to re-add it to Home Assistant.  This is in-line with the troubleshooting I attempted with another user, who noted that re-interviewing their device using the latest version caused a similar misconfiguration.
Did this work before?
Yes (please describe)
If yes, where did it work?
This worked when I initially set up my device approximately around October 2022.  During troubleshooting on Discord, it was reported that it appears the last working version was ZUI 8.15.0, driver 10.17.1
Attach Driver Logfile
zwave_js (1).log

On one hand I'm not sure why the endpoints are now no longer considered unnecessary. If I make one of you a test build of the driver, can you make a new log with that, e.g. by building a custom Z-Wave JS UI container?
On the other hand, we already use this compat flag for the CT100:
	"compat": {
		// The device has two endpoints. The temperature gets reported via the root, humidity is on endpoint 2.
		"mapRootReportsToEndpoint": 1,

Maybe it's the same for this device?


how to get Post ID after sending to channel

I want to know what the ID of the post, after sending to my channel
Is any way?

You might get a incoming message from that channel


Logo in a vector format

Where can I find the physical web logo in a vector format (preferably SVG)?

I'll upload it later today when I get into work. Can you say what you'd be using it for?

I'd like to experiment an app for Firefox OS, using mDNS first and then BLE when support becomes available later this year.

@scottjenson - Are there any Physical Web logo usage guidelines documented anywhere?
@gmarty - I made this one that you are welcome to use. I don't know if it is "official", meaning it does not include any type treatments, but it is a proportional representation of the mark itself. https://www.dropbox.com/s/igf92w0u8m4h1jl/UriBeacon Physical Web Vector.svg?dl=0

Added logo in .ai format (adobe illustrator) and three colors of png format in documentation/images/logo
https://github.com/google/physical-web/tree/master/documentation/images/logo


External data ingestion (Postgres database/ home server)

swap data from local file ingestion to database connection and query.

Linked with Data Ingestion issues since the ingestion method will now check for an available database table, upon failure try to create that from a local file, and on failure from that download the local file and ingest to a database before supplying the connection behind the scenes.


Week 3 MIlestones

Project
LLM-1 Karmayogi
Changes What was updated (new pages, weekly update, etc.)
3rd week milestones added
Notes
If there are any further notes.

Hey @divyansh-tripathi7 please resolve merge conflicts

Conflicts are resolved. Kindly merge it.


refactor(Logout): Redirect after logout

This PR ensures that users are redirected after logging out.
PS: No tests were added because it happens in a tricky part and after many attempts to mock the right things I had to forfeit. I don't think it is that important for such a small change though.

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Alternative Accept/Reject Port Type Checker

Just thinking out loud on constraining Accept Port Type with the Node without going through many layers of abstraction...

Mutate PortItem to know which port that is accepted.
In NodeViewer that calls _validate_accept_connection, maybe can consider to check if the mutated PortItem has the alternative constraint before falling back to the usual flow.
This alternative checking should be able to use the BaseNode identifier value to check against the "inherited base class of the Node" instead of adding every single possible subclasses node.

Random code for others to visualise what's going on:
class BasePublishNode(BaseNode):
    __identifier__ = "publish"
    allow_multiple_write = False

    def __init__(self):
        super().__init__()
        port = self.add_output(
            "write",
            multi_output=self.allow_multiple_write,
        )
        port_type = {
            "port_name": "src",
            "port_type": PortTypeEnum.IN.value,
            "node_type": f"{self.__identifier__}.PublishWriteNode",
        }
        self.add_accept_port_type(
            port,
            port_type,
        )

class PublishFileActionNode(BasePublishNode):
    NODE_NAME = "Publish File"
    allow_multiple_write = False

class PublishFileToManyActionNode(BasePublishNode):
    NODE_NAME = "Publish File to Many"
    allow_multiple_write = True

class PublishWriteNode(BaseNode):
    __identifier__ = "publish"
    NODE_NAME = "Publish Write"

    def __init__(self):
        super().__init__()
        self.set_color(164, 130, 0)
        self.add_text_input("write", "Path:")

        port = self.add_input("src", multi_input=False)
        port_type = {
            "port_name": "write",
            "port_type": PortTypeEnum.OUT.value,
            "node_type": f"publish.PublishFileToManyActionNode",  # Issue lies over here
        }
        self.add_accept_port_type(
            port,
            port_type,
        )

We have a situation where for BasePublishNode, the accept constraints for the write output port works fine assuming PublishWriteNode is the only node that take cares of the write path.
This works when trying to connect the write output port to any input of any nodes and it will fail to connect (the expected behaviour).
The MAJOR CONCERN here is that for PublishWriteNode, the src input port CAN BE CONNECTED TO ANY PORT IF WE DON'T SPECIFY ANY CONSTRAINTS. This leads to the situation above where if we want to add the constraint for any nodes that subclasses BasePublishNode, we need to keep adding each subclasses node to the acceptable port type.
Continuing from the above example code snippet:
        port = self.add_input("src", multi_input=False)
        port_type = {
            "port_name": "write",
            "port_type": PortTypeEnum.OUT.value,
            "node_type": f"publish.PublishFileToManyActionNode",  # First subclass
        }
        self.add_accept_port_type(
            port,
            port_type,
        )
       port_type = {
            "port_name": "write",
            "port_type": PortTypeEnum.OUT.value,
            "node_type": f"publish.PublishFileActionNode",  # Second subclass
        }
        self.add_accept_port_type(
            port,
            port_type,
        )
        # ... keep adding port type as required and that obviously start to lead into clunky code maintenance

Nearly forgot that any code fixes should also apply to Reject Port Checker logic...

Merge as part of #5


Download TSV of selected entities

Fixes #764
Behavior is there. Code is, I think, pretty good, though there may be some improvements left for a lodash/react expert to suggest. I'm not 100% satisfied that there aren't bugs lurking in corner cases.
Design needs help. Currently, bulk selection options (select/clear all) are not displayed always. In my mind, this is for 2 reasons:

selecting all can be expensive and could crash the user's browser for large tables so we don't want people invoking that just for fun
following the suggestion of modeling the UI after how GMail handles bulk selection

As a result, the bulk selection options need a place to live when they are rendered. At first, I put them to the right of the copy button but didn't like how it felt separate from related controls. It's currently in 2 places: next to the "download selected" button (to the left of the copy button) and just below the header of the table itself (like GMail). The former would be better if the copy button were right-justified to keep it from jumping around. The latter has an issue that the table body is pushed down into the pager. Finally, the labels/links need some padding that I didn't spend any time trying to add. I figured I could ask someone the best way to do that.
UPDATE 11/30: UI updated. Code cleaned up. No more extra state. No more changes to table.js.

Heads up: I just merged my copy data selections PR, so this one needs to account for the selectedEntities: _.keys(selectedEntities) change! Thanks!


Markdown not properly rendered

Description
I realized that some markdown is not properly rendered:
---
title: Sending native coins in Gno
section: Chain
---

By using the Banker module, you are able to send native Gno coins, such as `ugnot`
from one address to another. Each realm can inject the Banker module into the Gno
runtime and can cast it into a specific type of Banker. Each Banker type has its
own set of access rights for security reasons. Banker types are the following:

- `BankerTypeReadonly` - read-only access to coin balances,
- `BankerTypeOrigSend` - full access to coins sent with the transaction that
calls the banker,
- `BankerTypeRealmSend` - full access to coins that the realm itself owns,
including the ones sent with the transaction,
- `BankerTypeRealmIssue` - able to issue new coins.

As is currently on

While the break lines should not affect the render, like below:

@leohhhn This happens because you use a list symbol just after another parsed inline-block (the code one). It's a bug due to the markdown parser (markdown-to-jsw) that is known... You can try and you will have the same result here: https://markdown-to-jsx.quantizor.dev/
I'm gonna try to use another parser but meanwhile, if it's urgent, you can easily post the new content by avoiding this "-" symbol. You can use the long dash — or a : instead.


Expose ValidateOptions in HTTPClientStorageOptions

Adds the ability to configure the JWK validation options when using the HTTP storage.
This API is necessary (I think?) for https://github.com/MicahParks/keyfunc/issues/126 but I guess is also quite useful otherwise.

Thank you for the PR, @kevmo314.
There are a few other scenarios similar to this in the codebase at the moment, where default options are used without the ability to change them easily. See the below snippet.
https://github.com/MicahParks/jwkset/blob/0a74b0279c16a96447ea4e3b3391843a88cc8e84/http.go#L58-L61
If changing any of these now before I get to https://github.com/MicahParks/keyfunc/issues/126 makes anyone else's work easier, please open another PR or issue.

@kevmo314, you can use v0.5.20 to include the code from this PR.


ElementWrapper's .exists() no longer waiting for element to appear from 1.0.3 --> 1.0.4

Expected behavior
selector('criteria').exists(1000, j) should wait up to j milliseconds for the element to appear before returning false
Actual behavior
selector('criteria').exists(1000, j) immediately returns false if no element matching the criteria is present.
Steps to reproduce

Point taiko at a page which will have an element appear within x milliseconds, but is not present at page load
upon page load, have taiko check to see if that element is present, providing .exists() a timeout value greater than x

Versions
node: v12.16.1
taiko: v1.0.4

@nickanna42  Thanks for reporting, I could replicate the issue. Looks like .exists is not honouring the custom wait time given, we will look at fixing this soon.

@nickanna42 You can test this by installing the latest version of taiko from master using.
npm install https://github.com/getgauge/taiko


Use typedef instead of #define. Use int64_t to be unambiguous.

Same changes as https://github.com/icl-utk-edu/blaspp/pull/56. Requires that to be merged first.
Builds on top of PR #35.

CI is showing some errors while building on gpu_nvidia; e.g.:
lapackpp/test/cblas_wrappers.cc:43:5: error: cannot convert 'int*' to 'const lapack_int*


Multiple USER_FOUND actions being dispatched on page refresh

My implementation of redux-oidc is nearly identical to the redux-oidc-example, and I can share what bits need to be shared, I just don't know what is helpful right now. The USER_FOUND event is being fired several times when the page is refreshed. The screenshot shared below shows the ReduxDevTools listing of the events. LOADING_USER is fired twice, USER_EXPIRED is fired twice before that, and it ends with USER_FOUND twice. I've seen USER_FOUND three or four times also.
I was listening for the USER_FOUND event in my own middleware to fetch the user profile back into state like so:
export default function oidcUserLoaderMiddleware(store) {
  return next => action => {
    if (action.type == USER_FOUND) {
      store.dispatch(loadUserToStore())
    }

    return next(action)
  }
}

Because USER_FOUND is fired multiple times, I'm making a couple unnecessary calls to my API. They aren't really harmful, just unnecessary and that's how I noticed the duplicated dispatches.
I'm not sure if this is expected? If not, is this a bug in redux-oidc or a bug in my code that is causing redux-oidc to get confused?
https://www.dropbox.com/s/l7ie38ku9kl5u3y/Screenshot 2017-09-29 14.55.12.png?dl=0

How have you set up the userManager loading process? Are you using loadUser or the middleware?

Any update on this?

Sorry, missed the original notification. I'm using the middleware, and here is how I've configured it:
import createOidcMiddleware, { createUserManager } from 'redux-oidc'

import config from 'config' // eslint-disable-line import/no-unresolved

let uri = `${window.location.protocol}//${window.location.hostname}`
if (window.location.port && window.location.port != "80" && window.location.port != "443") {
  uri = `${uri}:${window.location.port}`
}

// oidc configuration
export const oidcConfig = {
  client_id: 'my-ui',
  redirect_uri: `${uri}/login-callback`,
  response_type: 'id_token token',
  scope: 'openid profile my-api',
  authority: config.authUrl,
  post_logout_redirect_uri: `${uri}/logout-callback`,
  silent_redirect_uri: `${uri}/silent_renew.html`,
  automaticSilentRenew: true,
  filterProtocolClaims: true,
  loadUserInfo: true
}

export const oidcUserManager = createUserManager(oidcConfig)

const oidcMiddleware = createOidcMiddleware(
  oidcUserManager,
  () => true, // shouldValidate
  false, // triggerAuthFlow - do not redir to oidc when user is expired
  '/login-callback' // callbackRoute
)

export default oidcMiddleware

The oidcMiddleware is then applied in my store the usual way.

No problem, thanks for sharing your configs. I think I've found the issue.
When you are using silent renew you don't need the middleware. Please use the loadUser helper function instead. This is how it is used in the example app. If you are accidentally using both, this will explain why USER_FOUND is dispatched multiple times.

Gotcha. I'm not sure which approach is more appropriate for my app right now, I'll have to do some reading. Thanks!

In general, setting up silent renew is the best approach. It allows for silently refreshing the token. There is no reason not to do it, unless your setup prevents it.

I think there is a problem in the middleware that is causing multiple dispatchs of 'redux-oidc/LOADING_USER' actions that cause identical number of 'redux-oidc/USER_FOUND' dispatchs:
This function:
export function middlewareHandler(next, action, userManager) {
  // prevent an infinite loop of dispatches of these action types (issue #30)
  if (action.type === USER_EXPIRED || action.type === LOADING_USER) {
    return next(action);
  }

  nextMiddleware = next;

  if (!storedUser || storedUser.expired) { // <----- condition
    next(loadingUser());
    userManager.getUser()
      .then(getUserCallback)
      .catch(errorCallback);
  }
  return next(action);
}

will trigger all actions dispatched while the condition returns true triggering the 'loadingUser' action on the next line and the related code.  Depending on each implementation that can cause problems; In my case my app code is just 'responding' to the first 'redux-oidc/USER_FOUND' action.
Thanks.

Were you able to solve this issue?

@maxmantz unfortunately no, but I haven't done more digging. I think @borntorun is on to something there. Even if I set automaticSilentRenew to false, I still get 3-4 USER_FOUND dispatches.

Fixed in beta.14. Thanks for the bug report and fix @nloding  & @borntorun.

@maxmantz awesome, I'm running beta.10, I'll update soon and confirm!

@maxmantz I'm now running beta.14 with the same config as above, except with automaticSilentRenew: false, and still getting multiple dispatches. Any thoughts?

No - from the information I have I cannot reproduce this behavior. However I strongly suggest switching from the middleware to the loadUser helper if you have silent renew set up (maybe you are already using both?).

@maxmantz I'll do some more looking, and see if I can switch from the middleware to loadUser and see how that changes things. I'll report back later either way!

I'm actually facing the same issue on 3.0.0-beta.16 and 3.0.0-beta.14
Removing middleware helped.

Also facing this issue on 3.0.0-beta.16
I don't want silent renew, so I just have the middleware set up (no loadUser) and am still seeing this.

I investigated this issue furhter and from my understanding it is caused by two things:

the middleware dispatches the action when the user is loaded,
the oidc provider also dispatches the action when the user is loaded.

I've tried removing the dispatch from both the middleware and oidc provider. The problems resulting from this are:

When the middleware dosen't dispatch the action, on page reload the user object is lost and a new login is necessary.
When the oidc provider doesn't dispatch the action, on silent renew, the new user object doesn't get dispatched, thus breaking functionality.

In light of this discovery, I think it is best to live with the (rather small) inconvenience of having multiple dispatches on startup instead of sacrificing important functionality at the core of this library.


TypeError [ERR_INVALID_ARG_TYPE]: The "size" argument must be of type number. Received an instance of Uint8Array

node:internal/validators:124
throw new ERR_INVALID_ARG_TYPE(name, 'number', value);
^
TypeError [ERR_INVALID_ARG_TYPE]: The "size" argument must be of type number. Received an instance of Uint8Array

Is this error a node version problem?

It's impossible to understand what happens with the existing info. Need minimalistic sample, how to reproduce, to reopen.
Note that this package has working tests: https://github.com/fontello/svg2ttf/blob/master/test/test.js. Maybe playing with those can help.


Add common orm and reactive persistence tests #367

@blafond I'm closing this one for now. You can send a new PR or re-open this one when you have updated the branch.
Thanks


Attach agent to existing host

As of Rancher 1.4, Rancher hosts are created when a new agent joins the environment.
In order to automate the management of Rancher nodes, it is necessary to automatically remove the rancher hosts of nodes that are decomissioned. To that end, a rancher_host resource type has been added to Terraform (see https://github.com/hashicorp/terraform/commit/1917646ec352769aca9e1260ccf78e9628aa4290).
However, the rancher_host resource type currently needs to avoid creating the host in Rancher (since it is created by launching a new agent), and instead detect existing hosts, based on the hostname of the agent.
Ideally, it would be better to tell the agent to attach to an existing host, so that we could:

create a host entry (also with labels) in the Rancher API
launch a new agent, passing it the host ID

This would greatly ease the automation of Rancher nodes lifecycle.

+1

Technically it's based on the host uuid so you could create the agent state volume and put it in the place the agent is going to read.  I'm confused as to what part of this is new to 1.4, or ever though...
Also FYI there is a setting to automatically remove hosts that are disconnected for longer than X minutes in 1.5.

It's not new in 1.4 for sure. Is there documentation about how to generate this? I can't find anything in the docs about host keys, .docker_uuid, .physical_uuid or the register API point that the agent seems to be using.


Issue while migrating from rtsp_simple_server to mediamtx

Which version are you using?
v1.9.0
Which operating system are you using?

[x] Linux amd64 standard
[ ] Linux amd64 Docker
[ ] Linux arm64 standard
[ ] Linux arm64 Docker
[ ] Linux arm7 standard
[ ] Linux arm7 Docker
[ ] Linux arm6 standard
[ ] Linux arm6 Docker
[ ] Windows amd64 standard
[ ] Windows amd64 Docker (WSL backend)
[ ] macOS amd64 standard
[ ] macOS amd64 Docker
[ ] Other (please describe)

Describe the issue
Not able to see the live stream through ffplay or VLC player.
We have a plan of migrating to mediaMTX from rtsp_simple_server. So, we ran pre-built binary and tested our application.
We could see connection establishment and recording the stream. But through ffplay command or vlc I'm not able to view the stream.
The same pusher code was working perfectly with rtsp_simple_server.
Describe how to replicate the issue

start the server
2024/09/04 13:08:50 INF MediaMTX v1.9.0
2024/09/04 13:08:50 INF configuration loaded from /home/ntirumalasetty/OshCor_FleetVideoMgt/SaiKrishna/mediamtx_v1.9.0_linux_amd64/mediamtx.yml
2024/09/04 13:08:50 DEB path manager created
2024/09/04 13:08:50 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP)
2024/09/04 13:08:50 INF [RTMP] listener opened on :1935
2024/09/04 13:08:50 INF [HLS] listener opened on :8888
2024/09/04 13:08:50 INF [WebRTC] listener opened on :8889 (HTTP), :8189 (ICE/UDP)
2024/09/04 13:08:50 INF [SRT] listener opened on :8890 (UDP)

publish with ...
Connected to IP address: <IP_ADDRESS>
[libx264 @ 0x7e6608006900] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x7e6608006900] profile High, level 3.0, 4:2:0, 8-bit
Output #0, h264, to 'result.h264':
Stream #0:0: Video: none, none, 640x480, q=2-31
USB camera Streaming started.

read with ...
ffplay rtsp://<IP_ADDRESS>:8554/live

Did you attach the server logs?

yes
Did you attach a network dump?

no
mediamtx_txt.txt

Please check the wireshark logs.
wireshark_log.zip.
Thanks,
Rambabu.

Hi Team,
I just want to update one observation here. I'm able to see the live through ffplay if I stream through command line instead of my pusher app. Please see the logs below.
1.Start the server
mediamtx_bin.txt
2.Publish with
ffmpeg_pusher.txt
3.Read with
ffplay_log.txt
MediaMTX is working with ffmpeg command pusher but not working with my pusher code. But, the same pusher code was working with the rtsp_simple_server earlier.
Can you please suggest me changes required to make pusher works for mediaMTX.
Thanks,
Rambabu.

Hi Team,
I am writing to follow up on my previous request regarding support for the RTSP streaming issue I mentioned on 05th Sep 2024. I understand you may have a busy schedule, but I would be truly grateful for your help as this matter is quite urgent for me.
Please let me know if you need any further information or clarification on my request. Your guidance would be invaluable in helping me move forward with this project.
Thank you so much for your time and consideration. I truly appreciate your assistance and look forward to your response.
Thanks,
Rambabu.


A javascript error occurred in the main process

I'm getting an error when keybase starts the GUI

my log id: 5cefee24e395b6bcf8deac1c
So I tried uninstalling keybase, but after (i assume) automatic updates, Windows 10 add/remove no longer points to the correct location in "C:\Users\alexm\AppData\Local\Package Cache". I've tried setting something up and even modifying the windows registry to point to the correct installer without much success.
Running the installer from the website; I get...

If I point it to the correct MSI within the Package Cache, I get

Ah, the installer is trying to use the older installer, to remove the original installation and I'm pointing it to the latest. But it doesn't exist anymore. I'm not sure why the installer for the existing installation has disappeared, but it's not something I've consciously removed.

cc @zanderz

I've managed to fix the issue, by manually removing keybase from the list of installed apps in the Windows registry and reinstalling the program.
It might be an idea to have the installer fall back to doing this, if it can't identify the location original installer.
If you agree this is the right course of action, I don't mind fixing the installer, which I presume is located here; https://github.com/keybase/client/tree/master/packaging/windows/WIXInstallers.

Actually this looks like a duplicate of #10619 with the original issue being a duplicate of #10627.


Cannot load Llama-3 8B Instruct, incompatible function arguments

TypeError: q_attn_forward_1(): incompatible function arguments. The following argument types are supported:
    1. (arg0: int, arg1: torch.Tensor, arg2: int, arg3: int, arg4: int, arg5: torch.Tensor, arg6: torch.Tensor, arg7: torch.Tensor, arg8: torch.Tensor, arg9: torch.Tensor, arg10: torch.Tensor, arg11: list[int], arg12: torch.Tensor) -> None

Hey @turboderp, latest version does not load a non-quantized model. Possibly q_handle being None does not sit well with that function call. Specifying 0 avoids this error, but it still fails on that forward call. I could dig into the issue but you probably could fix it quicker.

This is because quantized and unquantized models use different methods for attention, and I hadn't included a paged method for unquantized models in v0.1.0. It's in the dev branch now, so the dynamic generator should work with FP16 models too, and I think I'll release v0.1.1 soon to fix some other incoming issues too.

Thanks!

I released v0.1.1 now which should support FP16 models in the new generator.


Support static HTML from MDX content

An mdx field delivers an object with raw input and code output, which can be passed to a Contentlayer method to render it as a component.
It would be great to also have the HTML code (without interactivity or the ability to hydrate).
I would personally like this as a way to use Contentlayer outside a dynamic/server-side context (i.e. in a non-Next project). But we've also heard a scenario in which someone may want to render content statically to an XML feed where the code/interactivity is irrelevant, but the content (along with the semantic markup) is important.

This would also be helpful in writing scripts to generate static files (like writing an RSS feed xml file) where you may want some form of the compiled body available for consumption.

I've just ran into the same issue. I am trying to take posts written in MDX and add them to an RSS feed, but I just can't can't plain HTML back. Anyone had any luck with this?

I'm not yet convinced whether we should actually make this a built-in feature (in order to keep Contentlayer simple) but this should already be possible using the following approach:
import { defineDocumentType } from 'contentlayer/source-files'
import { bundleMDX } from 'mdx-bundler'
import * as ReactDOMServer from 'react-dom/server'
import { getMDXComponent } from 'mdx-bundler/client'

const mdxToHtml = async (mdxSource: string) => {
  const { code } = await bundleMDX({ source: mdxSource })
  const MDXLayout = getMDXComponent(code)
  // TODO add your own components here
  const element = MDXLayout({ components: {} })!
  const html = ReactDOMServer.renderToString(element)
  return html
}

const Post = defineDocumentType(() => ({
  name: 'Post',
  filePathPattern: `posts/**/*.mdx`,
  contentType: 'mdx',
  fields: {
    title: {
      type: 'string',
      required: true,
    },
  },
  computedFields: {
    mdxHtml: {
      type: 'string',
      resolve: async (doc) => mdxToHtml(doc.body.raw),
    },
  },
}))

I’m asking myself the same thing @ThePaulMcBride 😅
Have you found a fix? I can’t get it to build, getting the same error when using JSX:

The JSX syntax extension is not currently enabled
The esbuild loader for this file is currently set to js but it must be set to jsx to be able to parse JSX syntax. You can use "loader: { '.js': 'jsx' }" to do that.

Not too sure where I should change the loader for next.js, but will keep looking.

I have had no luck either. I'm currently just living with a crappy rss feed for now.

I used some native ReactDOMServer functions to handle this. Since I use mdx components in my content, I had to create some RSS feed specific components to use in order to render them as something that would be reasonable in an RSS feed.
Take a look at this script I wrote that builds the feed:
https://github.com/pmarsceill/this-modern-web/blob/main/scripts/rss-generator.mjs


Bundle Qty roll-up calculation of components on Invoice

When a Bundle item has 3 components of Qty 1 ea
We are seeing the InvoiceLine entity return roll-up qty = 0.99999 rather than 1.00000
{
"@odata.etag":"W/"JzEsNTYzNzE0NjA3Nzs4ODY1MDMwODMsNTYzNzE4MzI2Mic="","dataAreaId":"","RecIdLine":5637183262,"Qty":0.999999,"RequestDate":"","PriceRatio":0,"ShippedDate":"","RecIdHeader":5637217867,"EdiTransferred":0,"RequestedShipdate":"","InvoiceNo":"","LineTaxAmt":0,"ExtendedTaxAmount":"","UOM":"EA","yearLastDay":"2019-12-31 01:00:00.000","TaxPercent":0,"PromiseDate":"","ItemDesc":"MAKERSPACE 6-8 STEMLAB MATERIALS 3BX","LinUser3":0,"QtyToShip":3,"LineTaxableAmt":1499.99,"LocAdd2":"","LocAdd3":"","ReasonCd":"","LocAdd1":"","ExtendedPrice":1499.99,"QtyReturntoStk":0,"TaxState":"","LineTaxSched":"","LocState":"","CusItemId":"","LocName":"","LinUser4":0,"LinUser1":"","ItemId":"92931","LocZip":"","TaxFlag":"ITM","LineNo":3,"LinUser5":3,"LinUser2":0,"Price":1499.99,"LocCity":"","RecordType":"ITM","InventTransId":"LOT000003429","Taxable":"","LineTaxCd":"","LocCountry":"","InventDimId":"#00000001500005DD","LocId":"","ItemDesc2":"MAKERSPACE 6-8 STEMLAB MATERIALS 3BX"
}
Is this an issue of how this field is configured on the entity using an attribute or parameter? Calculated vs Roll-up?
Invoiced Qty isnt matching for 3 way matching validations
---
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c2e759b4-ee7e-56e5-6b32-3981042c6331
Version Independent ID: 7d1125a1-71b2-d0dc-f826-f9c472606223
Content: Revenue recognition bundles - Finance | Dynamics 365
Content Source: articles/finance/accounts-receivable/rev-rec-bundles.md
Service: dynamics-365-finance
Product: ****
Technology: ****
GitHub Login: @kweekley
Microsoft Alias: kweekley

Bug 734548 has been logged to address this issue.

Hi Wolfram66 - can you provide more context or detail so we can investigate further? The specific entity you are seeing this behavior in would be important here. Based on what I'm reading here this doesn't seem to be an issue with the documentation but potentially a product issue. I'd also recommend opening this as a support incident for proper traction and handling.

I am resolving this item as it is not a documentation issue. Please open a support request for your issue to be investigated further.


Postgresql not getting connected with golang - Golang Microservices: Caching with Redis

Hello Mario,
I was trying to replicate your tutorial here and facing hard time running it.
I am able to run following:

postgresql running in docker with your command so localhost, user, password and db are same
able to run migrate command so schema is there.
also able to connect to this instance and schema using table plus gui tool on mac
when i run following command
DATABASE_URL=postgres://user:password@localhost:5432/dbname?sslmode=disable REDIS=localhost:6379 go run .

it throws following error
2022/12/16 16:36:39 Could not initialize Database connection failed to connect to `host=/private/tmp user=najam database=`: dial error (dial unix /private/tmp/.s.PGSQL.5432: connect: no such file or directory)
exit status 1

Any idea what could be wrong

It looks like you figured it and fixed in https://github.com/MarioCarrion/videos/pull/12. So I'm closing the issue, thanks.


Fix typos in configuration comments

This merely updates the comments in the configuration
comments with proper spelling.

Note: CLA signed.

Thank you for cleaning this up!


R2000 fix

Several fixes to get this working with the R2000 sensor I have (more details in individual commit messages):

Actually publish amplitudes in the LaserScan messages
Re-enable parsing of packet type B data
Support non-default packet type and use packet type C instead of A on R2000 (no change to R2300)
Fix/workaround for (I assume?) older lidar that's using a shorter packet header than the latest PFSDP spec
Fix for streaming data over TCP (where one PFSDP packet != one TCP packet)

@bk-mtg thanks for your contribution! I will go through the comments in the coming days and get back. Nice work!

Again, nice work and thanks for the contribution! I have added some comments.

I've pushed some additional updates that address several of your comments; I think there's one comment left that I had some questions on, so waiting to hear back your thoughts on those to make further changes.
As in the other PR, I can verify that these changes compile, but I no longer have an R2000 to test against real hardware.

@bk-mtg https://github.com/PepperlFuchs/ROS_driver/pull/27 and https://github.com/PepperlFuchs/ROS_driver/pull/29 have been merged. Could you please rebase this PR by pulling in the latest master branch? This branch is out-of-date.

Okay, resolved a couple more comments and rebased.  Same caveats as before: I've tested that it builds, but no longer have an R2000 to test against hardware.

Oh, I should add: I caught a couple of extra code bugs in my TCP stream parsing code, so I fixed those too (they were places that I was returning out of a while loop instead of breaking.  Oops!).

@bk-mtg the commits look good now. Though there seems to some problem with merging for which the branch settings have to changes (I don't have access to that). In the mean time I will check the PR on my device and report back.


Create staging environment

Create staging app in heroku and staging branch in our repository to where we are going to make next pull requests. From staging branch we'll be making PRs to main branch.

staging branch created.