Main Thread Checker: UI API called on a background thread

Platform:

[x]  iOS
[ ]  Android

paranoid redacted npm ls:
<EMAIL_ADDRESS>├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>
Config:
Sentry.config(__CONFIG__.sentry.dsn, {
  deactivateStacktraceMerging: false,
  logLevel: SentryLog.Verbose,
  disableNativeIntegration: false,
  ignoreModulesExclude: [],
  ignoreModulesInclude: ["RNSentry"],
}).install();

I have following logs when booting my app, it's not a crash just something to be aware of:
=================================================================
Main Thread Checker: UI API called on a background thread: -[UIApplication setNetworkActivityIndicatorVisible:]
PID: 33386, TID: 4924766, Thread name: (none), Queue name: com.mixpanel.acf546f25cc02ab0b22ece3639f8a9a4.0x7f8530c19830, QoS: 0
Backtrace:
4   Driver                              0x000000010bfcceb1 -[Mixpanel updateNetworkActivityIndicator:] + 78
5   Driver                              0x000000010bfcaae5 -[Mixpanel flushQueue:endpoint:] + 567
6   Driver                              0x000000010bfca7cd __32-[Mixpanel flushWithCompletion:]_block_invoke + 117
7   libdispatch.dylib                   0x000000011464a2cf _dispatch_call_block_and_release + 12
8   libdispatch.dylib                   0x000000011464b314 _dispatch_client_callout + 8
9   libdispatch.dylib                   0x00000001146537a2 _dispatch_queue_serial_drain + 1162
10  libdispatch.dylib                   0x000000011465412a _dispatch_queue_invoke + 340
11  libdispatch.dylib                   0x000000011464ff15 _dispatch_queue_override_invoke + 733
12  libdispatch.dylib                   0x0000000114657044 _dispatch_root_queue_drain + 772
13  libdispatch.dylib                   0x0000000114656ce2 _dispatch_worker_thread3 + 132
14  libsystem_pthread.dylib             0x0000000114abe616 _pthread_wqthread + 1299
15  libsystem_pthread.dylib             0x0000000114abe0f1 start_wqthread + 13
2017-08-16 13:24:19.451131-0700 Driver[33386:4924766] [reports] Main Thread Checker: UI API called on a background thread: -[UIApplication setNetworkActivityIndicatorVisible:]
PID: 33386, TID: 4924766, Thread name: (none), Queue name: com.mixpanel.acf546f25cc02ab0b22ece3639f8a9a4.0x7f8530c19830, QoS: 0
Backtrace:
4   Driver                              0x000000010bfcceb1 -[Mixpanel updateNetworkActivityIndicator:] + 78
5   Driver                              0x000000010bfcaae5 -[Mixpanel flushQueue:endpoint:] + 567
6   Driver                              0x000000010bfca7cd __32-[Mixpanel flushWithCompletion:]_block_invoke + 117
7   libdispatch.dylib                   0x000000011464a2cf _dispatch_call_block_and_release + 12
8   libdispatch.dylib                   0x000000011464b314 _dispatch_client_callout + 8
9   libdispatch.dylib                   0x00000001146537a2 _dispatch_queue_serial_drain + 1162
10  libdispatch.dylib                   0x000000011465412a _dispatch_queue_invoke + 340
11  libdispatch.dylib                   0x000000011464ff15 _dispatch_queue_override_invoke + 733
12  libdispatch.dylib                   0x0000000114657044 _dispatch_root_queue_drain + 772
13  libdispatch.dylib                   0x0000000114656ce2 _dispatch_worker_thread3 + 132
14  libsystem_pthread.dylib             0x0000000114abe616 _pthread_wqthread + 1299
15  libsystem_pthread.dylib             0x0000000114abe0f1 start_wqthread + 13

=================================================================
Main Thread Checker: UI API called on a background thread: -[UIApplication applicationState]
PID: 33386, TID: 4924777, Thread name: (none), Queue name: com.mixpanel.acf546f25cc02ab0b22ece3639f8a9a4.0x7f8530c19830, QoS: 0
Backtrace:
4   Driver                              0x000000010bfcce4a +[Mixpanel inBackground] + 55
5   Driver                              0x000000010bfc9467 __36-[Mixpanel registerSuperProperties:]_block_invoke + 186
6   libdispatch.dylib                   0x000000011464a2cf _dispatch_call_block_and_release + 12
7   libdispatch.dylib                   0x000000011464b314 _dispatch_client_callout + 8
8   libdispatch.dylib                   0x00000001146537a2 _dispatch_queue_serial_drain + 1162
9   libdispatch.dylib                   0x000000011465412a _dispatch_queue_invoke + 340
10  libdispatch.dylib                   0x000000011464ff15 _dispatch_queue_override_invoke + 733
11  libdispatch.dylib                   0x0000000114657044 _dispatch_root_queue_drain + 772
12  libdispatch.dylib                   0x0000000114656ce2 _dispatch_worker_thread3 + 132
13  libsystem_pthread.dylib             0x0000000114abe616 _pthread_wqthread + 1299
14  libsystem_pthread.dylib             0x0000000114abe0f1 start_wqthread + 13
2017-08-16 13:23:19.899633-0700 Driver[33386:4924777] [reports] Main Thread Checker: UI API called on a background thread: -[UIApplication applicationState]
PID: 33386, TID: 4924777, Thread name: (none), Queue name: com.mixpanel.acf546f25cc02ab0b22ece3639f8a9a4.0x7f8530c19830, QoS: 0
Backtrace:
4   Driver                              0x000000010bfcce4a +[Mixpanel inBackground] + 55
5   Driver                              0x000000010bfc9467 __36-[Mixpanel registerSuperProperties:]_block_invoke + 186
6   libdispatch.dylib                   0x000000011464a2cf _dispatch_call_block_and_release + 12
7   libdispatch.dylib                   0x000000011464b314 _dispatch_client_callout + 8
8   libdispatch.dylib                   0x00000001146537a2 _dispatch_queue_serial_drain + 1162
9   libdispatch.dylib                   0x000000011465412a _dispatch_queue_invoke + 340
10  libdispatch.dylib                   0x000000011464ff15 _dispatch_queue_override_invoke + 733
11  libdispatch.dylib                   0x0000000114657044 _dispatch_root_queue_drain + 772
12  libdispatch.dylib                   0x0000000114656ce2 _dispatch_worker_thread3 + 132
13  libsystem_pthread.dylib             0x0000000114abe616 _pthread_wqthread + 1299
14  libsystem_pthread.dylib             0x0000000114abe0f1 start_wqthread + 13

@JAStanton Are you sure this is related to Sentry? Since the last frame of the crash indicates something about Mixpanel?

@HazAT these aren't crashes they are just logs.  But you're right they both do seem to be talking about Mixpanel. In my weary state I probably got you guys confused. No worries! Lets close this for now :) my apologies!


Overhaul logging and only do tracing when a debug flag is active

I think it's time to create a issue to track this as a TODO. The plugin's logging approach is pretty simplistic and heavy-handed—it's a homegrown log function that appends to a non-configurable file, re-opening a file handle on every call, and our logging is mostly trace-level detail that's quite verbose.
This is great when you're debugging or working on a new feature and want to see the server communication, so it probably served well in the plugin's early life, but I believe it has a real performance cost. Consider times when there is a lot of traffic exchange especially, like debugging: the server sends events for every thread start and thread death. If you're running code with Futures, for instance, ensime-vim spends a fair amount of time receiving and logging all these messages that we don't currently even handle.
We should consider a leveled logging approach to improve this, at least two levels, probably the equivalent of INFO and TRACE/DEBUG. Also, it would be nice to clean up and automate messy manual trace logging with decorators.
This might be a good newbie task since it don't require much familiarity with ENSIME specifics but you will get to know the code base in the process.
This perhaps could be broken into steps:

Move to a persistent logging.Logger instance, avoiding all the excess file handle opening. The log sink could be made configurable so e.g. test harnesses can send it to standard out/err (more palatable after trace output is not on by default…), while file remains the default since that's what is sensible when running in Vim.
Change trace logging to use an appropriate log level. Ideally try to avoid unnecessary work like pretty-formatting data structures when they're not being logged at higher levels (I don't think we actually explicitly do this now, but just an example). The level should be the INFO equivalent by default, with a Vim config variable to change it which we can ask users to set when troubleshooting.
Get rid of noisy trace logging statements that pervade the code base using decorators. Autologging looks nice, there are other similar solutions if we're willing to accept a pip dependency for this.

If we're willing to use a third-party dep it might be easy to just skip to step 3 and get most of this for free.

I'd be happy with this landing in two or even a single pull, provided we go the decorator route.
Autologging does look quite nice. That being said, I think the attractiveness of the package lies in the decorators, and I'm not sure they're worth the cost of requiring users to install a third package (although I could go either way on this since I really don't like reinventing things).
Thoughts on package vs. roll our own?

I think the most important parts of this were covered by #323, and since I'd agree with not adding a dependency to get the magic decorators that won't even be a user-visible improvement, I think I'll close this for now.
The logging isn't very configurable at this point, just an environment variable to toggle between INFO or DEBUG log level, but if a desire for more comes up in practice we can handle it as a new issue.


enumerate atlases

for small graphs

This has been done in our data table. Will continue to add more as we get them, but all known/used small graph atlases are documented with their name, source, region count, and location on our servers.


[NEW ALGORITHM] Josephus Problem

Issue will be closed if:

You mention more than one algorithm. You can create a separate issue for each algorithm once the current one is completed.
You propose an algorithm that is already present or has been mentioned in a previous issue.
You create a new issue without completing your previous issue.

Note: These actions will be taken seriously. Failure to follow the guidelines may result in the immediate closure of your issue.

Name:
[NEW ALGORITHM]  Josephus Problem Algorithm
About:
Propose a new algorithm to be added to the repository
A recursive approach to solving the elimination-based problem.The Josephus Problem recursively eliminates every
k-th person in a circle of N people until one remains. The recursive formula is: J(N,k)=(J(N−1,k)+k) modN where J(1,k)=0.
The Josephus Problem algorithm in recursion is a way to find the "safe position" in a group of N people standing in a circle, where every k-th person is eliminated in a loop until only one person remains. The recursive approach uses a mathematical formula to determine the position of the last person left.

Labels:
new algorithm, gssoc-ext, hacktoberfest, level1

Assignees:

[x] Contributor in GSSoC-ext
[x] Want to work on it

@pankaj-bind please assign this issue to me.

assigned


feat(deps): upgrade runtime dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-runtime-dependencies-1.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1403

Questions ?
Please refer to the Backport tool documentation


Assigning a bool to modulate.a (color alpha) works in debug if declared but not in release.

Godot version
3.4.4.stable.official
System information
Windows 10
Issue description
The title pretty much explains it.
This works is debug but not in release:
extends Node2D

onready var icon = $Icon as Sprite

func _ready() -> void:
    icon.modulate.a = false

However if you don't declare and simply assign it, you do get the error of assign type bool to an alpha color.
extends Node2D

func _ready() -> void:
    $Icon.modulate.a = false

I don't know what is intended, if this should fail or not, but it should at least be consistent in both debug and release.
Steps to reproduce

Drop the icon.png into a 2D scene
Assign a script to the scene and declare the icon
In _ready set the icon's modulate alpha to false
Export a release build and compare

I have attached a simple project .zip with a windows release build in its project folder.
Minimal reproduction project

ModulateAlphaWithBool.zip

Can you test 3.5.rc4? Type information is now included in release builds, so this kind of typing discrepancy should be gone now.

Yes it works in 3.5.rc4. Thanks!
However, it highlights a difference when writing gdscript in general, should it throw an error when you don't declare it and work fine if you do?
onready var icon = $Icon as Sprite

func _ready() -> void:
   # Works
   icon.modulate.a = false

   # Gives error
   $Icon.modulate.a = false

Or should we just convert the type in script int(false), and avoid these little things? Just incase Godot under the hood doesn't just do it for you.


webpub manifest parser set to 3.0.1

Description
Change: https://github.com/ThePalaceProject/webpub-manifest-parser/pull/103

Motivation and Context
Recent changes to the webpub parser needed to be included into the CM.

How Has This Been Tested?
Unit tests have been run.

Checklist

[ ] I have updated the documentation accordingly.
[x] All new and existing tests passed.

There's a test failure but only on one specific version. Suggests the test might be fragile... Going to try to trigger the action again.

There's a test failure but only on one specific version. Suggests the test might be fragile... Going to try to trigger the action again.

Ran this locally on 3.10 to make sure. The tests all passed.

I started CI rerunning, it does seem that failure is likely unrelated.


Unable to load plugin , windows 10. Latest nightly mta version. (not x64)

Describe the bug
Have tried to load plugin for windows, but keeps telling me server was unable to load the plugin king.dll. I have it in deathmatch/modules folder.
To reproduce

Expected behaviour
To load the plugin
Screenshots

Version
Latest from nightly builds
Additional context

Yes. Thank you for your issue. This problem depends on #55. You can fix it if you download sqlite3.dll and put it into the server folder like:


Update grpc-proxy.md

2018/12/08 23:03:00 [FATAL] 1.5.10. unknown protocol "grpc"

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

This feature is in master and not the latest 1.5.10 release.  I am use docker image fabiolb/fabio:1.5.10-go1.11.1

No worries. I've merged this yesterday and the wrong version in the docs slipped through. I'll try to push a 1.5.11 release in the coming days. Just updated the documentation.


Allow playbooks to work for remote machines

Related to OSBS-7600
This is a sort of breaking change in the sense that you now need to specify inventory files when running the deploy and cleanup playbooks.

oc command can work with remote ocp. Is there any need to run oc command on remote machine, instead of just login via oc to remote ocp instance?

oc command can work with remote ocp. Is there any need to run oc command on remote machine, instead of just login via oc to remote ocp instance?

I believe the playbooks could mostly work from localhost except for the tasks which set up directories for persistent volumes. I don't think openshift can set those up automatically, I remember trying that but I think I hit a SELinux issue.
So technically, oc does not have to be run on the remote machine, but there is a  task that does.

ok then.
Please note that in future we may have OCP pre-configured and we need only to deploy osbs namespaces. However for now I'm fine with this approach.


[CT-1222] [CT-1220] [Bug] dbt documentation does not list macros that were migrated from dbt-utils

Is this a new bug in dbt-core?

[X] I believe this is a new bug in dbt-core
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
dbt documentation currently has no mention of the macros that were migrated from dbt-utils in March (https://github.com/dbt-labs/dbt-core/issues/4813) and subsequently released.
For example for date-diff, dbt-utils doc mentions: "DEPRECATED: This macro is now provided in dbt Core. It is no longer available in dbt_utils and backwards compatibility will be removed in a future version of the package."
Expected Behavior
Having list of macros included in dbt-core and expected behaviour documented like they were in dbt-utils
Steps To Reproduce
Search for macros in the dbt documentation and find nothing. https://docs.getdbt.com/
Search for macros in dbt-utils and see that they are deprecated. https://github.com/dbt-labs/dbt-utils#datediff-source
Relevant log output
No response
Environment
dbt 1.2

Which database adapter are you using with dbt?
No response
Additional Context
No response

Fair! We do have this: https://docs.getdbt.com/reference/dbt-jinja-functions/cross-database-macros
But that page is not automatically updated today. Whereas, if we included them here, they would be
@dbeatty10 Curious if you have a thought here. Relevant to our convo earlier re: the expanded user persona for cross-db macros as utilities / building blocks

@jtcohen6 auto-generated documentation for our cross-db macros à la Sphinx docs could be handy for the expanded user persona for cross-db macros as utilities / building blocks.
@ali-infostrux thanks for reaching out about this!
Did you happen to try the search bar in the upper right corner of https://docs.getdbt.com ?

When I typed "datediff" I got the following results.  The first four results are all Developer Blog posts, but the next two link to our list of macros.

Admittedly, this page might be a bit hard to find within the navigation section on the left:

@jtcohen6 auto-generated documentation for our cross-db macros à la Sphinx docs could be handy for the expanded user persona for cross-db macros as utilities / building blocks.

What I was realizing, thanks to this issue, is that we already have auto-generated docs for macros — it's dbt-docs! In our codebase, instead of adding docstrings a la Python/Sphinx, we'd need to add description + args: https://docs.getdbt.com/reference/macro-properties
Bonus points if we could:

Figure out a way to serve the same structured information (from manifest.json) in docs.getdbt.com, to avoid the need to repeat ourselves
Use Jinja's parser / AST (?) to auto-detect arguments for macros, and record those in the manifest, in case users haven't documented themselves. Sorta relevant: https://github.com/dbt-labs/dbt-core/issues/4999

The more immediate question to answer right now: Are there still good reasons to exclude "internal" macros from the dbt-docs site?
Especially now that we're adding in utilities that users might want to know about, beyond the internal guts that they should happily ignore.
This caused confusion for at least one user, and I imagine it's done the same for many more.

+1 for dbt-docs 💪
I wonder if including "internal" macros for dbt docs generate would help make it more discoverable when there is a project macro that is overriding an "internal" macro?


fix for disablebuynearhigh never triggering because price is always 0.0, addition of debug info.

fixed disablebuynearhigh not working at all.
added more info to the logger, feel free to discard this.
Type of change
Please make your selection.

[ x] Bug fix (non-breaking change which fixes an issue)
[ x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration.
Checklist:

[x ] My code follows the style guidelines of this project
[x ] I have performed a self-review of my own code
[not needed ] I have commented my code, particularly in hard-to-understand areas
[not needed ] I have made corresponding changes to the documentation
[ x] My changes generate no new warnings
[ ????] I have added pytest unit tests that prove my fix is effective or that my feature works
[ x] New and existing unit tests pass locally with my changes
[ ???] Any dependent changes have been merged and published in downstream modules
[ x] I have checked my code and corrected any misspellings

Thanks, I've added your PR to "beta". Will merge in next release.


Error upgrading to Microsoft.Azure.WebJobs.Extensions.ServiceBus 5.0.0

Query/Question
We have Azure Durable Function with session based service bus trigger. I upgraded the Microsoft.Azure.WebJobs.Extensions.ServiceBus package from 4.3.0 to 5.0.0
After the upgrade, the function won't start with this error:
Microsoft.Azure.Functions.Extensions: Method not found: 'Microsoft.Extensions.Configuration.IConfigurationBuilder Microsoft.Azure.WebJobs.Hosting.IWebJobsConfigurationBuilder.get_ConfigurationBuilder()'.
Value cannot be null. (Parameter 'provider')

Do I need to install/ upgrade additional package?
Environment:

Name and version of the Library package used: Microsoft.Azure.WebJobs.Extensions.ServiceBus 5.0.0
Hosting platform or OS and .NET runtime version (dotnet --info output for .NET Core projects): CoreTools 3.0.3734 32 bit, function in .NET Core 3.1
IDE and version : Visual Studio Version 16.11.5

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

This looks similar to https://github.com/Azure/azure-webjobs-sdk/issues/2059

Can you try the workaround mentioned in https://github.com/Azure/azure-webjobs-sdk/issues/2059#issuecomment-448769239

I haven't been able to repro this. Can you include the contents of your functions csproj?
Also, just to confirm, you are hitting this error locally when running from VS?

@adeliab, I haven't been able to repro the error. Are you still experiencing the issue?


deprecate AUR specific short command options

Pacaur provides two sets of command options, one for AUR only specific actions and another one that extends regular pacman options. While this allows quite a lot of flexibility in the way users can use pacaur, this has however the downside of being quite complex to maintain, not to mention being completely ugly.
Also, the usage of two sets of options that somewhat overlap isn't straightforward to understand, as some options haven't the same meaning in one set or another (f.e. -y). To this day, I still see users mixing both sets of options and not understanding how to use pacaur without actually reading the man page.
For theses reasons, I'd like to deprecate the AUR specific short command options, and use only "long" options, similarly to what auracle (cower-ng, see #708) does. F.e, instead of using-s and --search, simply implement search as the AUR only option. The pacman extension set should stay unchanged, still allowing the short -s and long --search options, to be used with -S or --sync.
Implementing a temporary "translator" of the old AUR-only options to the new one with a warning message might be needed here.
Also, simplifiying the getops structure would help. See this reference and blog post to handle nested getops in a much readable form.

For the sake of consistency and code simplification, each pacman command that is extended to the AUR should have a direct AUR specific command equivalent:
-S  -> sync
-Ss -> search
-Si -> info
-Sw -> downloadonly
-Su -> sysupgrade
-Sc -> clean
-Qu -> check

makepkg should be renamed to downloadonly (as per pacman convention)
update should be renamed to sysupgrade (as per pacman convention)
clean should be added (#715)
download should be removed. There isn't a pacman equivalent as ABS integration isn't done in pacaur for a variety of reason, it can be done better done directly by cower -d / auracle download, and could be readded once pacman eventually integrates ABS.

Why don't you use the getopt command instead of the getopts built-in? It is much more powerful and supports native long option names. This command is provided by util-linux which is in the base and base-devel group. No more $OPTARG ugly hacks needed! See /usr/share/doc/util-linux/getopt/getopt-parse.bash.

There are a number of reasons that made me choose getopts over getopt in the past: built-in, more robust with option that requires an argument - though I don't know if that still the case, but the bottom line is that I hate both. I am planning to use the parseopts library provided by makepkg instead.

Partially done in f67d43bfbda08bdd9f6ef86729f57a4a71580f68, bb0222622e8f13702c35fc482018ebc316ef789b, 9291462bef4467c7a992c076c617e73e06b5d061 and 60add4bb62e38b6c713e6fd40094a925a32f25e3.
Still missing:

clean and cleanall implementation (#715)
selective target implementation (still undecided what do do here)

As stated in https://github.com/rmarquis/pacaur/pull/744#discussion_r131551592 it seems odd that downloadonly builds a package?!

-Sw -> downloadonly

makes sense.

makepkg should be renamed to downloadonly (as per pacman convention)

This is what I don't get probably.

The logic behind this choice is to have similarly names flags as the repo operation. Since -Sw is downloadonly, I choose it as the -Swa equivalent too, but this might not be a wise decision. With retrospect, the long pacman options might not be known very well if at all, so this won't help in clearing any confusion.
While sync, info, search and clean are unambiguous, downloadonly, sysupgrade and upgrades might very well be. Here is another proposal:
-Sw -> buildonly
-Su -> upgrade
-Qu -> check

downloadonly could be kept for downloading the PKGBUILD only (equivalent to current -d short option).

Adjusted in 668393e762c07db0a52920c02bca3708a6416108.

Download only / clone only is better left to cower/auracle or any other command line shortcut.


Rename methods for Swift 4 compatibility

Hi there 👋
When using your pod on the swift4 branch, Xcode 9.0 / Swift 4 still gave me errors for methods that got renamed.
Methods that got renamed:

.cropped(to:) to .cropping(to:)
.applyingFilter(_, parameters:) to .applyingFilter(_, withInputParameters:)

Have a nice weekend!

@rmnblm
Please try version 4 instead of branch swift4 instead.

@onevcat
I did but the methods are still incorrect, e.g. https://github.com/onevcat/Kingfisher/blob/4.0.1/Sources/Filter.swift#L74

Nope, it should not or you are using an old Xcode 9 beta version. See the CI result of your p-r yourself. https://travis-ci.org/onevcat/Kingfisher/builds/276195803


Failure to Reconnect to Oracle 12c.

Environment
node: v8.6.0
oracle db: 2.0.15
Knex version: 0.14.2
Database + version: oracle 12c
OS: REPL 3.10.0-693.17.1.el7.x86_64 #1 SMP Sun Jan 14 10:36:03 EST 2018 x86_64 x86_64 x86_64 GNU/Linux
Select applicable tempalate from below.
If issue is about oracledb support tag @ atiertant. For MSSql tag @ Grimace1975 .
Rest of dialects doesn't need tags.
Bug

Explain what kind of behaviour you are getting and how you think it should do

What I see: Knex does not reconnect after the db bounces.
What I expect: Knex should reconnect after the db bounces.

Error message

Error: ORA-03114: not connected to ORACLE

Reduced test code, for example in https://npm.runkit.com/knex or if it needs real
database connection to mysql or postgresql, then single file example which initializes
needed data and demonstrates the problem.

My test procedure:

Start the DB.
Run the code below.
Stop the DB.
Once I see the 'Error: ORA-03113: end-of-file on communication channel' error.
Wait a few seconds then restart the DB.  Once the DB is up I expect to start seeing the SYSDATE again.

'use strict';

var knex = require('knex')({
    client : 'oracledb',
    connection: {
        "user": "user",
        "password": "pwd",
        "database": "sid",
        "host": "host:port"
    },
    debug: false,
    pool: {
        "min": 0,
        "max": 3
    }
});

 function  exitIfDBIsDown() {
    knex.raw('select sysdate from dual').then(resp => {
       console.log(resp);
    }).catch(async err => {
        console.log(err);
    });
}

setInterval(exitIfDBIsDown, 2*1000);

example output:

[ { SYSDATE: 2018-02-27T02:09:24.000Z } ]
[ { SYSDATE: 2018-02-27T02:09:25.000Z } ]
[ { SYSDATE: 2018-02-27T02:09:27.000Z } ]
[ { SYSDATE: 2018-02-27T02:09:29.000Z } ]
[ { SYSDATE: 2018-02-27T02:09:31.000Z } ]
[ { SYSDATE: 2018-02-27T02:09:33.000Z } ]
[ { SYSDATE: 2018-02-27T02:09:35.000Z } ]
[ { SYSDATE: 2018-02-27T02:09:37.000Z } ]
Error: ORA-03113: end-of-file on communication channel
Process ID: 461
Session ID: 139 Serial number:<PHONE_NUMBER>
Error: ORA-03114: not connected to ORACLE
Error: ORA-03114: not connected to ORACLE
Error: ORA-03114: not connected to ORACLE
Error: ORA-03114: not connected to ORACLE
Error: ORA-03114: not connected to ORACLE
Error: ORA-03114: not connected to ORACLE
Error: ORA-03114: not connected to ORACLE
Error: ORA-03114: not connected to ORACLE
Error: ORA-03114: not connected to ORACLE
....

I see the Error: ORA-03114: not connected to ORACLE for the rest of the life of the program. I know the db is running because I'm able to connect to it using sqlplus.  Also if I restart the app it connects and once again prints the sysdate.
@atiertant

please try again with 0.14.4. 0.14.2 was badly broken.

@elhigu it's still broken in 0.14.4.
Thanks in advance for working on an oracledb fix.

Below is the stack for the error
Trace: Error: ORA-03114: not connected to ORACLE
    at knex.raw.then.catch.err (/IdeaProjects/attendance-resource/app/contest.js:22:17)
    at tryCatcher (/IdeaProjects/attendance-resource/app/node_modules/knex/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/IdeaProjects/attendance-resource/app/node_modules/knex/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/IdeaProjects/attendance-resource/app/node_modules/knex/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 (/IdeaProjects/attendance-resource/app/node_modules/knex/node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises (/IdeaProjects/attendance-resource/app/node_modules/knex/node_modules/bluebird/js/release/promise.js:689:18)
    at Async._drainQueue (/IdeaProjects/attendance-resource/app/node_modules/knex/node_modules/bluebird/js/release/async.js:133:16)
    at Async._drainQueues (/IdeaProjects/attendance-resource/app/node_modules/knex/node_modules/bluebird/js/release/async.js:143:10)
    at Immediate.Async.drainQueues (/IdeaProjects/attendance-resource/app/node_modules/knex/node_modules/bluebird/js/release/async.js:17:14)
    at runCallback (timers.js:781:20)
    at tryOnImmediate (timers.js:743:5)
    at processImmediate [as _immediateCallback] (timers.js:714:5)

Hi @elhigu, is there any update on this? I see this issue on my project too.
Thanks for all the hard work!

Nope, I still havent got time to even finish mssql.

I having the same issue with oracle and the error ORA-03114.
This is what I discovered:

knex destroy connections that has the flag __knex__disposed /src/client.js#L261
the oracle driver set this flag only for connection errors /src/dialects/oracle/index.js#L148
only ['ORA-12514', 'NJS-040', 'NJS-024', 'NJS-003', 'NJS-024'] are considered connections errors /src/dialects/oracle/index.js#L18

The solution seems to be to add ORA-03114 to the error connection list

@jfgodoy thanks a lot, should be easy fix then 👍

I having the same issue with oracledb client.
If you restart Oracle database, the application can not reconnect to DB with error ORA-03114.
any plan to fix this?

@jfgodoy The solution seems to be to add ORA-03114 to the error connection list
I think
@atiertant  Does the solution given by @jfgodoy solve the issue? If so is there a PR for it?

@cemremengu did not have time to test but oracledb dialect inherit from oracle dialect.

We have this issue, with Knex 0.14.3. What is currently the best way to workaround it until the PR is merged? Are knex versions below 0.14.2 work?

@beltschatsar even that it helps, it doesn't sound like root cause for the problem that oracle is not reconnecting. I mean, knex shouldn't need to wait idletimeout evict connections from pool, whose sockets were closed.

Totally Agree with you @elhigu . My comment was for a workaround.

Had the same problem, and I solve it on a curious way, but I did it.
When I ask for my method getOracleClient, if I already have a connection at the beginning I was doing nothing. Now I test my Query. If I have a connection error like Ora-03114 or Ora-03135 I set my client to undefined and I ask for a new connection. That works.  Don't reset your client on some other errors because it won't works.
** My code is from typescript.
const knexClient: knex;
export async function getOracleClient(): Promise {
// If we lost the connection. We need to reset the client and get a new connection.
// ONLY if we lost a connection. Because doing an Undefined, on other errors, will create other connection errors like Pool if full.
// The best way to validate if the connection is OK, is just test a small query
if (knexClient) {
await client
.select(xxx)
.from(xxx)
.catch(async (err: any) => {
if (err.errorNum === 3114 || err.errorNum === 3135) {
// The only time we can get new connection is when error are from a lost connection : 3114 and 3135
// By setting an undefined, it will enter in the other IF and get a new connection.
knexClient= undefined;
}
});
}
if (!knexClient) {
knexClient= knex(connectOptions);
}
return knexClient
}
function  exitIfDBIsDown() {
knex.raw('select sysdate from dual').then(resp => {
console.log(resp);
}).catch(async err => {
console.log(err);
});
}
public async findById(id: string): Promise {
try {
  const oracleConnection: knex = await getOracleClient();
  const result = await oracleConnection
    .select(xxx)
    .from(xxxx)
    .where(xxx);
}

}

Hi Team,
Any update on this issue i am using oracle knex .16.3 version for the same getting same issue and project is dependent on this as will be using this frquesntly

@soumyamishra12 Could you please try 0.16.6-oracle-fix ? It has improved Oracle error handling quite a bit, I wonder if it addresses the specific problem that you are having.

@soumyamishra12 this one https://github.com/tgriesser/knex/pull/2608 we are currently unable to run oracle tests so its a risky business to do changes there :(

@elhigu ahahaha, GMTA. Yeah, exactly for that reason I published it as a separate tag so that at least someone could test it.

@elhigu @kibertoad  have just changed it to 0.16.4 in my server and it's working correctly.Is it fixed for the version?

@soumyamishra12 Now that's interesting 😅. Must have been a side-effects for some of the fixes done there. Please let us know if it keeps being stable for you after a while.

@kibertoad Sure will observe for someday and let you know

@kibertoad I have tracked this issue but it's inconsistent, after 4 or 5 times calling it's again showing 3114 error. Please let me know if we can find a fix for this issue in some build

@soumyamishra12. Yes. Please try 0.16.6-oracle-fix

@kibertoad you mean to say 0.16.6 version?

I have deployed new change and took 0.16.6-oracle-fix  still the bug exists. It's not consistent enough after 1 or 2 hr interval if I try throws the error.

@soumyamishra12 could you paste the error message? Are you sure it is the same one?

Hello there,
@elhigu Any updates for this issue?

Running 0.16.6-oracle-fix and it still does not recover from the ORA-03114 error. Here's the error/stack returned:
Error: ORA-03114: not connected to ORACLE\n
    at Connection.connection.executeAsync (/home/my-app/node_modules/knex/lib/dialects/oracledb/index.js:184:16)\n
    at /home/my-app/node_modules/knex/lib/dialects/oracledb/index.js:258:16\nFrom previous event:\n
    at Client_Oracledb._query (/home/my-app/node_modules/knex/lib/dialects/oracledb/index.js:250:10)\n
    at Client_Oracledb.query (/home/my-app/node_modules/knex/lib/client.js:202:17)\n
    at Runner.<anonymous> (/home/my-app/node_modules/knex/lib/runner.js:146:36)\nFrom previous event:\n
    at /home/my-app/node_modules/knex/lib/runner.js:48:21\n
    at runCallback (timers.js:705:18)\n
    at tryOnImmediate (timers.js:676:5)\nFrom previous event:\n
    at Runner.run (/home/my-app/node_modules/knex/lib/runner.js:34:31)\n
    at Builder.Target.then (/home/my-app/node_modules/knex/lib/interface.js:20:43)\n
    at my-appService.then [as getSummary] (/home/my-app/src/services/my-app.js:70:8)\n
    at getSummary (/home/my-app/src/routes/api/my-app.js:24:40)\n
    at handler (/home/my-app/src/routes/index.js:63:48)\n
    at Layer.handle [as handle_request] (/home/my-app/node_modules/express/lib/router/layer.js:95:5)\n
    at next (/home/my-app/node_modules/express/lib/router/route.js:137:13)\n
    at next (/home/my-app/src/services/validation.js:29:7)\n
    at handler (/home/my-app/src/routes/index.js:63:48)\n
    at Layer.handle [as handle_request] (/home/my-app/node_modules/express/lib/router/layer.js:95:5)\n
    at next (/home/my-app/node_modules/express/lib/router/route.js:137:13)\n
    at runner.then.errors (/home/my-app/node_modules/express-validator/check/check.js:16:7)

I've been able to implement a workaround for this issue for the time being using a Proxy wrapper. It relies upon on having a simple db.js module that establishes the knex object before exporting it and using it in other modules.
Basically, I'm using the query-error event to trigger a re-establishment of the connection and changing the value of the myDb variable. The Proxy is used to ensure that modules that have already imported db end up using the updated myDb instead of the statically exported one. Definitely not ideal but it seems to work.
// db.js
import config from 'config'
import knex from 'knex'
import logger from './logger';

const myDbDbConfig = config.get('db.myDb')

// eslint-disable-next-line import/no-mutable-exports
let myDb = knex(myDbDbConfig)

myDb.on('query-error', (err) => {
  // Reconnect when we find a 3114 error (until knex issue #2608 is merged)
  if (err.message.indexOf(`ORA-03114`) > -1) {
    logger.error(`Encountered ORA-03114 database connection error. Automatically reconnecting.`)
    myDb = knex(myDbDbConfig)
  }
})

const handler = {
  // Uses the `myDb` variable in the module instead of exported instance which is static
  get: (_target, propKey) => (...args) => myDb[propKey].apply(this, args),
}

/*
  Using Proxy to allow us to intercept method calls and pass them
  through the `get` interceptor, which points them towards the non-exported
  `myDb` variable, which will reconnect automatically using the event listener

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy
  http://2ality.com/2015/10/intercepting-method-calls.html
*/
const db = new Proxy(myDb, handler)

export default db

And then in my other files:
// other.js
import db from "./db";
// ...
return db.withSchema('foo').select('*')...

Sounds like something in that implementation is failing... IIRC it was not merged because tests were missing...

@icj217 Can you try latest master?

@icj217 Just released 0.18.0-next2, would appreciate if you could give it a try and report back.

@kibertoad Just tested out 0.18.0-next2 and it seems to be working for me!

@soumyamishra12 It seems that updated fix is working; could you also try 0.18.0-next2?

Closing due to inactivity, might be fixed already.


Can't download Novels with option 1

Prerequisites

[x] Did you read FAQ section in readme.md?
[x] Did you test with the latest releases or commit ?
[x] Did you search for existing issues in Issues?

Description
When selecting member_id the novels will be skipped. Only manually downloading each one (option 14) will work. Even "folder.jpg" and "bg_folder.jpg" will be skipped if novels are on the profile.
Steps to Reproduce

Select option 1 and enter member id.
Novels will be skipped.
Cry.

Expected behavior: Novels should be downloaded with option 1.
Actual behavior: Novels are skipped.
Log file: [Attach the pixivutil.log file in the application folder, recommended to delete the old file, reproduce the issue, and upload the newly generated file here]
Versions
You can get this information from executing PixivUtil2.py --help.
Latest version available in https://github.com/Nandaka/PixivUtil2/releases

Novels downloading isn't implemented


Please use Maven instead of relying on local static binaries

Describe the bug
Currently, the project relies on mod JARs in the "modsWithCompat" folder of the repository in order to compile.
Declaring dependencies on locally available JARs in a project is a very bad idea, as they're less convenient to update, unnecessarily increase the size of the Git repository, and - most importantly - introduce another potential attack vector for malware that injects itself into JAR files, such as Fractureiser.
It's good practice, and much safer, to declare dependencies using Maven repositories, that are then dynamically downloaded as-needed from official sources.
Instead of declaring a flatDir { } repository, you would add something like Cursemaven and/or Modrinth Maven to the repositories { } block, then declare a dependency on each mod as described in their documentation. (Better yet, you could use the mod's own Maven repository, if they have one.)
To Reproduce
Steps to reproduce the behavior:

Build the project.
It declares dependencies on mods in the modsWithCompat folder.

Expected behavior
The Gradle build script should declare dependencies on Maven artifacts.
Desktop (please complete the following information):

OS: N/A
Minecraft Version: N/A
Version: >=1.2.5 (https://github.com/B1n-ry/Youre-in-grave-danger/commit/322b526f8b95d65c677080c7c6e11b84065633d8)

Additional context
Also, if a given dependency isn't always required to run the mod (such as every mod that loads code conditionally), you can declare a dependency on it using modCompileOnly instead of modImplementation, which may make the mod compile more quickly (IIRC).
Screenshots
N/A

Thanks for tour input. I've already done this in the 1.20 branch, but I'll be sure to change other branches in development now too as soon as I get back to working on them.
I started using the modsWithCompat thing because it seemed easier to handle the version ID there, but when I come to think of it now you're probably right that downloading files is slower and more complicated (as well as potentially more dangerous).
Also I use mods own mavens when I can. Rhe mods in modsWithCompat are those I couldn't find/figure out a maven to.
Also I think I tried once "modCompileOnly", but if I recall correctly, it didn't work properly. I will give it another shot though, and see if it works this time.
Thanks again. I will close the issue whenever I update the 1.19 branch, which probably is the only branch other than 1.20 I will keep updated for now

I'm glad you're open to fixing this!
In terms of version IDs, Modrinth Maven allows you to use the version numbers specified by the mods uploaded to it, which are generally more readable / logical than a random string of numbers.
Of the mods in modsWithCompat, only Flan and Inventorio aren't on Modrinth - the former is missing its 1.19.2 version, while the latter isn't present at all.
For modCompileOnly - note that it doesn't include the mod it's declaring a dependency on in the development environment (runClient / runServer); for that, you would want modImplementation. Also note that I'm not great with Gradle dependencies and their formatting, so I may be wrong about it :P

I honestly don't think I'll bother with versions below 1.20 from now on (maybe on some occasion, but 1.19 seems to work reliably enough for most people anyway). Thank you anyway for explaining the different "dependency" or "inclusion" gradle methods (at least so I actually understand them better). I've started using modCompileOnly in the 1.20 branch, and it seems to be working well, especially since I can still test without some mods being up to date, or having some issues with my dev environment. Thanks!


Improve the wordcount plugin

Solve several issues with the wordcount plugin, and resolve all the
problems raised in #864

Add a way to format the status message
Keep the code modular and clean, using Airline's API
Add new documentation to support the new format feature
Correct the default behaviour. Keep it disabled by default (by the
documentation), but allow enabling the extension to add it to the
default statusline sections

I opened issue #864, this refactors the extension to be more like the others.

Thank you! I lack the vimscript skills, but I write Markdown all day in Vim.

@RichardDooling You did the original wordcount plugin! Thanks for doing the initial work, I just cleaned it up to play nice with the rest of Airline.

Do you see the issue in #898?
Do :behave mswin
And then Shift-Select any string of text with the wordcount extension
enabled.
Thanks,
Rick Dooling
On Thu, Oct 8, 2015 at 9:09 PM, somini<EMAIL_ADDRESS>wrote:

@RichardDooling https://github.com/RichardDooling You did the original
wordcount plugin! Thanks for doing the initial work, I just cleaned it up
to play nice with the rest of Airline.
—
Reply to this email directly or view it on GitHub
https://github.com/bling/vim-airline/pull/866#issuecomment-146737195.

--
rd

thanks for for the PR.  actually, the extension should be on by default.  where in the documentation are you see this contradicting?
i was wondering how you got around the snippet expansion error.  how'd you stubble upon using printf?

Yeah, it seems I misread that. I'll need to rebase this to the latest airline version, and I'll set it as enabled by default.
As for the printf and catching the error, I got that error during test, so I just checked :h :catch and there's a snippet there to catch specific errors:
:catch /^Vim\%((\a\+)\)\=:E123/	" catch error E123
@RichardDooling I commented on issue #868 , I can't reproduce your problem.

I've rebased this into the latest master, please force pull if you want to update your branch.

hmm, i'm getting a snippet expansion error again after the rebase (or maybe i didn't test correctly the first time).  when i try to expand a snippet, it errors out and the statusline is lost.  #862 was the primary reason i switched the code to using autocmds.

I don't use snippets (not until now, actually), but I installed snipmate and can't reproduce. Maybe it's only on UtilSnip, I can test it tomorrow.

for me the error happened with both ultisnip and neosnippet.

I'll have to test it with those plugins then, just give me a couple days.

I tested with UltiSnip and it worked fine for me on Linux.

both ultisnip and neosnippet error out for me, on OSX, vim 7.4.769.  until this is resolved i can't merge this.
you can also apply the format improvement to the current version of the extension instead.

Yeah, I think I'll try that then. Thanks for keeping this alive.

Yes, thank you. I wish I knew enough to fix it myself. I use this
constantly.
All of my problems went away when I removed behave mswin from my .vimrc.
I don't use Ultisnips or neosnippet.
Thank you again.
On Sun, Oct 25, 2015 at 6:29 PM, somini<EMAIL_ADDRESS>wrote:

Yeah, I think I'll try that then. Thanks for keeping this alive.
—
Reply to this email directly or view it on GitHub
https://github.com/bling/vim-airline/pull/866#issuecomment-150980376.

--
rd

I have a patch that implements the format improvement for the original extension, should I open another PR?
I still much prefer this version, because it's more configurable, but since I can't reproduce the bug on Windows nor on Linux, I don't know how to fix it. It will continue to live on my fork.

closing, as #883 has been merged.


[BUG] Invalid session token on login in Safari DevTools

Describe the bug
An "Invalid-session-token" error occurs when trying to log in via devtools in Safari, regardless of using Github or Google for authentication.

Steps To Reproduce
Open your project in Safari.
Access DevTools.
Attempt to login using either Github or Google.
An error displays the "Invalid-session-token".
Expected behavior
Successful login within Safari DevTools using the chosen authentication method (Github or Google).
Packages
@refinedev/devtools version "^1.1.32"
@refinedev/cli: "^2.16.21"
@refinedev/core: "^4.47.1"
@refinedev/devtools: "^1.1.32"
@refinedev/kbar: "^1.3.6"
Safari Version: 17.5
Date: June 13, 2024
Additional Context
The same issue occurs when signing in with Github, resulting in the error message.
Google Signin doesn't provide an error message but redirects back to the login page repeatedly.

Still no access to devtools @refine-bot

I can reproduce this on Chrome

I can reproduce this on Chrome

so have you been able to login yet?

No, it always redirect me back to the login page.

No, it always redirected me back to the login page.

Seems like a major issue then, let's see if anyone can address it out

I also have this issue. Side note- why exactly is login required to access devtools?

Same, can not open devtools. Using chrome browser.  Whoami can not detect browser.
## System:
 - OS: Windows 11 10.0.22631
 - CPU: (16) x64 AMD Ryzen 7 6800H with Radeon Graphics
## Binaries:
 - Node: 20.12.1 - C:\Program Files\nodejs\node.EXE
 - Yarn: 1.22.21 - C:\Program Files\nodejs\yarn.CMD
 - npm: 10.8.1 - C:\Program Files\nodejs\npm.CMD
## Browsers:
 - Chrome: Not Found

## Refine Packages:
 - @refinedev/antd: 5.40.0
 - @refinedev/cli: 2.16.33
 - @refinedev/core: 4.51.0
 - @refinedev/devtools: 1.2.3
 - @refinedev/kbar: 1.3.12
 - @refinedev/nestjs-query: 1.3.0
 - @refinedev/react-router-v6: 4.5.11

Same, can not open devtools. Using chrome browser. Whoami can not detect browser.
## System:
 - OS: Windows 11 10.0.22631
 - CPU: (16) x64 AMD Ryzen 7 6800H with Radeon Graphics
## Binaries:
 - Node: 20.12.1 - C:\Program Files\nodejs\node.EXE
 - Yarn: 1.22.21 - C:\Program Files\nodejs\yarn.CMD
 - npm: 10.8.1 - C:\Program Files\nodejs\npm.CMD
## Browsers:
 - Chrome: Not Found

## Refine Packages:
 - @refinedev/antd: 5.40.0
 - @refinedev/cli: 2.16.33
 - @refinedev/core: 4.51.0
 - @refinedev/devtools: 1.2.3
 - @refinedev/kbar: 1.3.12
 - @refinedev/nestjs-query: 1.3.0
 - @refinedev/react-router-v6: 4.5.11

So I guess it's not a Mac specific issue

Sorry for the issue everyone! We've just merged a fix for this issue and it will be released in the next couple hours 🚀  I'll update here when its released and you can validate if its resolved 🙏

Changes are just deployed, you can update your dependencies:

<EMAIL_ADDRESS><EMAIL_ADDRESS>
🚀

Closing this for now after #6065, feel free to re-open if the issue continues 🙏

Thank you @aliemir
I am currently at the hospital as my mom is admitted, will check when I am home! Thank you for the fix


[FEATURE REQ] Set client LocationIP field by default when using Azure.Monitor.OpenTelemetry.AspNetCore

Library name
Azure.Monitor.OpenTelemetry.AspNetCore
Please describe the feature.
Related to: https://github.com/Azure/azure-sdk-for-net/issues/42850
When using Application Insights SDK, the location IP field is set by default. When using Azure.Monitor.OpenTelemetry.AspNetCore, users need to enable this collection by setting client.address attribute on the activity using Enrich or processor. https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-add-modify?tabs=aspnetcore#set-the-user-ip.
Opening this issue to enable the collection of LocationIP by default when using Azure.Monitor.OpenTelemetry.AspNetCore

@vishweshbankwar @onionhammer I've logged an issue on the underlying OpenTelemetry.Instrumentation.AspNetCore SDK since that's where the root cause lies: https://github.com/open-telemetry/opentelemetry-dotnet-contrib/issues/2231
While it's true this could be worked-around by the AzureMonitor distro, I agree with the assessment on #42850 that it's probably ideal if it were fixed in the underlying SDK.


Design and Unit Test Cases

MVP Features

[ ] Define plugin defaults (no options passed) #5

[ ] Templates

[ ] What should we define as the default template output type? (html?)
[ ] What should the default output path and organization (directory structure) for each template?

[ ] Emitted Assets

[ ] Should there be any consideration for css chunks? Or should this happen automagically?
[ ] If css chunks belong to a template, should it be added into a "head" tag? Or should it be manually prescribed to a specific location.
[ ] Should there be a default vendor chunk? Should it be determined by minChunks: module => module.resource.test(/node_modules/)
[ ] What is the default vendor chunk name?
[ ] Should we employ code sharing (CommonsChunkPlugin) across entry points?
[ ] What is the default shared chunk name?
[ ] Should these be called '[name].chunk.js'?
[ ] Which files should be included in each template?
[ ] Where should emitted assets go? (Respect output property?/Combination)
[ ] Order of scripts inside template should just work every time regardless of the case

[ ] Long Term Vendor Caching

[ ] Inline bootstrap chunk?
[ ] chunkhash? md5 webpack plugin? handing hashing on other files?

[ ] Options to pass

[ ] specify name of vendor chunk
[ ] specify name of shared chunk
[ ] turn shared chunk'ing on or off
[ ] specify template output extension (one or each)
[ ] specify template output directory (one or each)
[ ] specify template output filename (one or each)
[ ] specify template language? ejs? hbs? etc. (passed through html-webpack-plugin)
[ ] specify different template for each entry point?

[ ] Handling Configuration Conflicts

[ ] Conflicts with CommonsChunkPlugin?
[ ] Conflicts with html-webpack-plugin?
[ ] Should error? warning? gracefully inherit behavior?

Optional Features To Investigate

[ ] http2 integration?

[ ] AgressiveSplittingPlugin?

[ ] html-webpack-plugin doesn't currently support this but I believe these split chunks are specified in stats.compilation.entrypoints

[ ] h/2 Push? Prefetch? Manifest Generation?

[ ] Service Worker

[ ] offline-plugin / sw-precache-plugin (cc @nekr @addyosmani)
[ ] What are some possible defaults for server rendered applications in these regards that make sense?

[ ] separate vendors

[ ] Legacy apps' entry points may contain outdated or different versions of vendor packages. It would make more sense in that regards that if there are drastic differences in vendors that each entry has a separate vendor.
[ ] To go super meta there could be benefit (at the cost of an extra network request, but gains in cache-ability), with this feature, a commons vendor could be created for each "entry" as well. This is farfetched however valid.

Wanted to start a thought-dump here on what we think should be a part of the initial design. The first requirements will probably support what we are needing in-house, but I would still like to have a set of defaults pulled in.
cc// @kenwheeler @developit because you showed some mild interest in this plugin, etc. Would love input if you have it.

Tagged @nekr @addyosmani for ideas on service worker integration, are there any reasonable defaults that could be derrived or added.

@mipearson @nateberkopec would love to have you and the rails community involved as this could really mutually benefit as you all consider replacing Sprockets with webpack by default.

Alright I'm going to tackle the first one since it's pretty easy for defaults.
Scenario (Defaults)
Fixture
webpack.config.js
const MultipageWebpackPlugin = require(multipage-webpack-plugin);

const config = {
  entry: {
    a: './src/a.js',
    b: './src/b.js'
  },
  output: {
    filename: '[name].chunk.js',
    path: path.join(__dirname, "dist")
  },
  module: {
    /* ... */
  },
  plugins: [
    new MultipageWebpackPlugin()
  ]
};

module.exports = config;

Templates
What should we define as the default template output type?
We use the most simple and compatible template across MVC frameworks and that is .html.
Since under the hood this POC leverages html-webpack-plugin the output/emitted template file makes sense to be .html. By default there would be automatic handling of asset location etc.
What should the default output path and organization (directory structure) for each template?
Each template should be emitted into their own subdirectory. This sub directory by default would be sane to match the entry name. This way each dist can be accessed as a "dist" and served with simple http-server or liteserver or whatever else is out there.
Example derived from fixture above:
├── dist/
│   ├── a/
│   ├─── index.html
│   ├── b/
│   ├─── index.html

cc @collinstork

Well, offline-plugin for sure 😁
If serious, it depends by a multi-page website's design. Reasonable default might be app-shell + streaming it with content requested from the server (server responds only with content, without app-shell).

@NekR That lines up nicely with my use-case for sure. I offline the app shell, which is then basically an offline Markdown reader, and then request & cache .md files from a content/ directory as-needed.

@developit is it SPA? For SPA it's easier and offline-plugin indeed supports that use case. For multi-page.. A but trucker and there are possibly perf downsides on big projects (which is why  FB requested some additional features in SW spec to fix that). Anyway, it would be great to add multi-page app-shell support to the offline-plugin.

It's an SPA currently yeah.   It's true though, I'd be giving up a bit of caching for the shell's HTML.

Yes this is why I listed as optional feature. I'm not 100% sure yet how the best practice for implementing service worker support for multi page applications.

@NekR if you were interested I could create a separate issue which you could discuss potential design options for multi page apps.

@TheLarkInn yeah, that would great :-)

Created #7 for separate discussion thread.

Thanks for the cc!
Reading through the problem statement in the readme, one thing that would be valuable is understanding the scope of the solution for multi-page apps. Is the goal here to create a turnkey all-in-one solution so folks don't have to thing about their Webpack plugin config per entry/route for anything else? I ask because scope might help understand whether it makes sense or not to take in H/2 splitting, offline and some of the other optional pieces mentioned.

What should we define as the default template output type?

HTML sgtm. I assume that under the hood, either the HTML Webpack plugin or otherwise would still let you configure this per entry in case you're working with a mix of client and server-side templates.

Should there be any consideration for css chunks? Or should this happen automagically?

I wouldn't say this should happen automagically, but is the goal to split these out so you're only loading in the styles for an entry/template/route rather than the whole kitchen sink?

Should there be a default vendor chunk? Should it be determined by minChunks: module => module.resource.test(/node_modules/)

I think that'd be pretty nice.

Should these be called '[name].chunk.js'?

👍

Order of scripts inside template should just work every time regardless of the case

Yeah. Agree. Although, I assume you're abstracting away the end-user needing to think about script order at all to an extent.

Inline bootstrap chunk?

👍
Hashing by default also sounds good. TBH, I'd love it if the output of this project was code-splitting per route/entry, with common vendor chunks handled for you automatically and any long-term caching settings pre-setup and bootstrapping issues handled for you too. These are the pieces I most often find myself having to manually add and wrangle in Webpack.
Aggressive splitting is (for now) something I would actually have folks opt-into by manually adding it in or opting in via a boolean config. Just to make sure they're enabling it when they know their server setup is going to be able to take advantage of it (H/2 Push or otherwise).

@addyosmani

After having tried to enable "offline by default" workflows in a few different CLI/starter kit projects over the last 2 years, I've come to the opinion that this should be an opt-in (either boolean or install yourself).

Oh, I  didn't realize that Sean wants it by default in this plugin. @TheLarkInn plugin inside plugin? Hmm.

Too often I've found developers unaware of Service Worker trying to understand why their new builds are still using "old" code, but they don't realize it's the offline caching kicking in.

Yeah, this happens all the time with react-boilerplate and offline-plugin. Maybe it can show "Update is ready" toast by default.

Thought: provide a configuration the developer can use to instantiate OfflinePlugin, but keep them as peers?

Is the goal here to create a turnkey all-in-one solution so folks don't have to thing about their Webpack plugin config per entry/route for anything else?

Yes essentially. So for most MVC server routed web applications, you will have an entry point for essentially every "rendered page instance". The challenge in this is that when you get to managing hashed chunks and files, that you would essentially have to updated the changed hash files for every single page affected.
For single page apps, html-webpack-plugin makes this super simple because it manages the injection of scripts into a "templated" .html file.
To take this approach it essentially requires the users to configure like seen here
const templatesFn = (modules, twigRoot, assetsRoot, shared) => {
  return Object.keys(modules).map((entryName) => { // for each entry point
    return new HtmlWebpackPlugin({ // create html-webpack-plugin instance
      template: `${assetsRoot}/webpack.template.hbs`, //use a base html template tailored to MVC lang (in our case we use twig for Laravel)
      filename: `${twigRoot}/webpack-bundles/${entryName}.twig`, // We need to specify the output path for each of these twig templates (they could lie in a non-patterned location
      chunks: ['inline', 'vendors', entryName, `${shared}`] // Only include the following: entry chunk for that page, shared chunk if applicable, inline for the webpack bootstrap, and a vendors chunk
    })
  });
}

Most of this information for out of the box standard index.html templates would require little to know extra configuration besides the plugin reading the config and generating the correct html-webpack-plugin instances.
In the same way, CommonsChunkPlugin is also applied behind the scenes so that this can be easily implemented by the user.

Oh, I didn't realize that Sean wants it by default in this plugin. @TheLarkInn plugin inside plugin? Hmm.

@NekR Yeah, a lot of struggles with using html-webpack-plugin is that you have to configure a new instance of that plugin for every "page" in a multipage app.

provide a configuration the developer can use to instantiate OfflinePlugin, but keep them as peers? This was my initial thoughts. It could be as simple as MultipageWebpackPlugin({offline: true}) or it could be more involved but would still be treated as peers.

Hashing by default also sounds good. TBH, I'd love it if the output of this project was code-splitting per route/entry, with common vendor chunks handled for you automatically and any long-term caching settings pre-setup and bootstrapping issues handled for you too. These are the pieces I most often find myself having to manually add and wrangle in Webpack.

Yes agreed. Currently I don't have the hashing portions of this setup, but I think I'll have a separate story and design for that to determine how the plugin should detect a production environment build (besides node-env etc. However, the CommonsChunkPlugins (for the exception of the dynamic vendor chunking) has been implemented so far. (I stopped there because I wanted to do a more strict TDD and BDD for this plugin.

Why would you generate HTML files for every single page/route? Can't you just generate a template which will be populated by the server with contents?

That is possible, it wouldn't be for EVERY route IE (generated template files). There are exceptions however the idea is that for every unique template or page your want 1 single entry and an emitted template.

That is possible, it wouldn't be for EVERY route IE (generated template files). There are exceptions however the idea is that for every unique template or page your want 1 single entry and an emitted template.


fix: tsconfig.json

Currently the TSConfig.json errors out as the rootDir is inherited as "/src" which makes it 0 files and every single other file marked by include (["."]) is outside the rootDir, creating ~~90 TS errors
the allowJS is also specified to allow the scripts/ to use the tsconfig and not default to whatever the default for a jsconfig.json are

Why was allowJS removed? Also you forgot to update the PR description :)

Why was allowJS removed?
Skillz said on discord the prefers not having allowJS and rather in the future rewrite the js files into ts ones


Load llm into free vram on multiple gpus

Can you add the auto_split function from exllama2 into your nodes?
So it will distribute over multiple gpus vram.
Thank you.

Sorry for the delay, as far as I can tell auto_split is the default behavior when nothing is specified but I added an explicit gpu_split field. It should function the same way it does in exllama, eg. 8192, 4096 will allocate 8gb to the first device and 4gb to the second one. I don't have multiple gpus to test so let me know if it works.

It seems like auto_split was using a different loading method, but I added it now. Should work by specifying auto in gpu_split.

Thanks for your update, but now the node does not work anymore when updating exllamav2. theres a torch error.

Thank you, works again. You did a great job with this node as i use it very often.


Create Milestone Summaries

As part of larger project a write up of certain features is required.
This is mainly here as a reminder to discuss what needs to be written up.
However, there is a duplicate use-case for the code-base where parts of milestone write-ups can often be reused as documentation.

Absolutely. I think the milestone report would be the current documentation, and the near term plans.


Remove redundant ItemsControl inside our ItemsControl

We were using an ItemsControl inside our ItemsControl and binding the
nested ItemsControl's source to our ItemsControl's source. Wut?

thx @mrahhal


Discover ip address of the physical infra provider

This PR is able to:

Discover the Ip address of the physical infra providers

After the refresh:

@blomquisg Can we merge this PR?

@CharlleDaniel I would add something like parse_ems to your ems_inv_to_hashes here which sets the @data[:ems][:hostname] property, then save_ems_inventory should update it.
Fun fact you can update the :uid_ems and :api_version this way too which is what VMware and RHEV are doing.

Hi @blomquisg and @agrare, I agree with the sugestions, thanks for the review! I will work on it.  :+1:

@blomquisg, @agrare, @AndreyMenezes and @rodneyhbrown7  I close this PR because I open a new PR in the manageiq-provider.


Update README.md

Looks like this package has moved—Xcode didn't like this link

Oh man, not moved just a terrible typo. Thank you so much!


Section 3 is confusing

The way I read this page, section 3 is about how to deploy your app after you have changed it.  The first 2 tabs of section 3 (Deploy using VS Code and Deploy using CLI) don't support that.  They should be rewritten to describe how to deploy the app again, now that the app has been created.  For example:
VS Code: to deploy this App from VSCode, ensure you are the "Azure App Services" extension installed and click on Azure "A" in the left-hand panel of VS Code.  From there...
CLI: to deploy this App from the Azure CLI, use the command:
az webapp update --name= --resource-group=
--
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: af57ca1d-6109-b46b-ec0e-50fb35d8981a
Version Independent ID: 2f24c98c-d89f-8693-2618-d49b42b94b51
Content: Quickstart: Deploy a Python (Django or Flask) web app to Azure - Azure App Service
Content Source: articles/app-service/quickstart-python.md
Service: app-service
GitHub Login: @mijacobs
Microsoft Alias: mijacobs

Thank you for sharing this feedback. We agree that further clarity is needed. We will take this feedback to our next meeting with the product group and doc team to review it further.
For now, we will archive this thread. Please ping us if anything further is required.


fullscreen mode should only show the single window with no decorations

dont show other windows

I don't understand what you want to mean.
Are you saying that, on a full screen container, the focused window inside it should occupy the entire container, even if there are other windows tiled with it?

yes

Might be nice if you could do both, make a distinction between fullscreening a window and fullscreening/maximizing a container.
As an example, I use mpv to watch Twitch streams via streamlink and then I use chatterino for chat, putting those windows together in a container makes sense and is nice, but when I do that and try to fullscreen mpv it now does the container instead. Same thing for if you're watching a video in a web browser and try to fullscreen it. Definitely would prefer it to fullscreen just the relevant window, then the current functionality can be included as a separate thing you can do.

I personally do not use fullscreen a lot, and when I do (while playing a movie on TV for example) there's only a single window in the container, so it gets fullscreen with the titlebar hidden.
I have never kinda needed such feature, therefore it not being implemented although I thought on it when I first implemented containers.
I am implementing it now.


F10 does not step into the entry point of an executable with mainCRTStartup() or WinMainCRTStartup()

If I load an executable target into the debugger that has been built without the CRT main() or WinMain() entry points and instead was built with mainCRTStartup() or WinMainCRTStartup(), hitting F10 does not place me at the beginning of my entry point but instead somewhere inside ntdll.dll.
Here's a sample application:
#include <stdio.h>

int mainCRTStartup()
{
    int x = 5;
    int y = 10;

    printf("%d + %d = %d\n", x, y, x + y);
    return 0;
}

and build it with
cl /nologo /O2 /Zi /W3 /WX /GS- main.c /link /fixed /incremental:no /opt:icf /opt:ref /subsystem:console ucrt.lib

If I replace the mainCRTStartup() with main() and run the same command (excluding the ucrt.lib at the end), F10 will step directly into the beginning of main().

WinMainCRTStartup should work, but the debugger was not previously looking for mainCRTStartup. Can you try pulling 25c31b0d7782ab36b9c15c1069e8a7c1eb390919, building, and running again?

Yes, that worked perfectly. Thank you, Ryan! And I'm sorry about the wrong information regarding WinMainCRTStartup(). I must've been testing something else and misconstrued it as that instead.


feat: support com_query update sql request

ref: https://github.com/cectc/dbpack/issues/
Ⅰ. Describe what this PR did
support com_query update sql request
Ⅱ. Does this pull request fix one issue?
https://github.com/CECTC/dbpack/issues/104
Ⅲ. Why don't you add test cases (unit test/integration test)?
Tested in my own environment
Ⅳ. Describe how to verify it
Run delete sql in com_query
Ⅴ. Special notes for reviews
No

Codecov Report

Merging #126 (0329287) into dev (db0b68c) will decrease coverage by 0.23%.
The diff coverage is 0.00%.

:exclamation: Current head 0329287 differs from pull request most recent head fa59ba9. Consider uploading reports for the commit fa59ba9 to get more accurate results

@@            Coverage Diff             @@
##              dev     #126      +/-   ##
==========================================
- Coverage   48.23%   48.00%   -0.24%
==========================================
  Files          55       55
  Lines        5759     5787      +28
==========================================
  Hits         2778     2778
- Misses       2738     2766      +28
  Partials      243      243

Impacted Files
Coverage Δ

pkg/filter/dt/exec/query_delete.go
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update db0b68c...fa59ba9. Read the comment docs.

LGTM


istio 1.17.1 pulling istio pilot 1.18.0-alpha

Bug Description
A month ago I followed the helm instructions to install istio onto a GKE cluster. Everything worked swimmingly.
Yesterday afternoon, sidecar injection started failing with the message:
Error creating: admission webhook "namespace.sidecar-injector.istio.io" denied the request: failed to run injection template: template: inject:212:12: executing "inject" at <.EstimatedConcurrency>: can't evaluate field EstimatedConcurrency in type *inject.SidecarTemplateData

Upon investigation, we noticed the istiod container while released with helm @v1.17.1 was scheduled to use the image gcr.io/istio-testing/pilot:latest running at version
2023-04-04T18:40:40.411154Z	info	version: 1.18-alpha.f991abdcfdf51fcc965dd42529907615cddc709f-f991abdcfdf51fcc965dd42529907615cddc709f-Clean

I believe the following two things are incorrect:

The default values.yaml file should not default to pulling the latest image, especially if using a specific chart version (see values.yaml here)
The default repository (hub?) should resolve to istio-release, not istio-testing

Version
istioctl version
client version: 1.17.0
control plane version: 1.17.1
data plane version: 1.16.2 (17 proxies), 1.17.1 (7 proxies)

kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.25.6
Kustomize Version: v4.5.7
Server Version: v1.25.7-gke.1000

Additional Information
No response

For those looking for a solution, I was able to override the pilot.image field in Values.yaml inline to gcr.io/istio-release/pilot:1.17.1 and everything started working again

Same thing happening for 1.17.2.
I was able to fix it by following @cessien 's instructions

Do not just override the values. if you are seeing this, you are installing wrong. Please ensure you are installing in properly supported methods; patching it after is going to lead to headaches and other bugs.
https://istio.io/ has a comprehensive set of ways to install Istio. git clone && helm install ./manifests/blah is not one of them.
helm template --version 1.17.1 istio/istiod

Or downloading the .tar.gz from the github release are valid ways.

I'm using ArgoCD to install helm charts in my repo. My approach is to run a helm pull for each istio component and install it in it's namespaces accordingly.
It's ArgoCD's job to run kubectl apply -f istio-base into the cluster with its manifests
I modify the values.yaml to get the desired istio config.
Why would that be considered wrong?

can you give more info? seems fine to me
$ helm pull istio/istiod
$ tar xzvf istiod-1.17.1.tgz
$ cat istiod/values.yaml | rg tag:
  tag: ""
  tag: 1.17.1

The issue is easy to reproduce, here are the steps:

Install istio via istioctl and do istioctl version check, the result in my case is:
└──> ./istio-1.17.2/bin/istioctl version
client version: 1.17.2
control plane version: 1.17.2
data plane version: 1.17.2 (1 proxies)

Install over the helm charts for 1.72.2(I am doing argocd application install):

base
gateway

└──> ./istio-1.17.2/bin/istioctl version
client version: 1.17.2
control plane version: 1.17.2
data plane version: 1.17.2 (3 proxies)

Install also the helm chart:

istiod
└──> ./istio-1.17.2/bin/istioctl version
client version: 1.17.2
control plane version: 1.18-alpha.c7b1007c98efb7753930176578ff4b9e635f7be4
data plane version: 1.17.2 (3 proxies)

Before the following commit(or around it), there was no problem to transition from istioctl installation to the helm installation and it has worked fine for months on my lab k8s:
https://github.com/istio/istio/commit/97baf44e71d48b5d5de025f6fcbcbe66fcc72713
After the above commit the only "hybrid" setup that kind of works is to only install the gateway chart after the istioctl setup -> the moment you add the istiod chart and delete one of your ReplicaSet or/and StatefulSet you will get:
Error creating: admission webhook "namespace.sidecar-injector.istio.io" denied the request: failed to run injection template: template: inject:212:12: executing "inject" at <.EstimatedConcurrency>: can't evaluate field EstimatedConcurrency in type *inject.SidecarTemplateData

The issue is easy to reproduce, here are the steps:

Thank you just found this after setting up istio for the first time and running into the  exact same issue you had.  adding an override in argocd to set the pilot.image to 1.17.2 worked for me as well.

Before the following commit(or around it), there was no problem to use the wrong pilot image and transition from istioctl installation to the helm installation - it has worked fine for months on my lab k8s:

I would personally phrase it that there was a big problem, you just didn't know it yet.

I mean is it intended to make people use the istio-testing images(not a question rly)

No, my intent is that any users should NOT use this image. Hence why I am suggesting if you are seeing it used, you installed "wrong" (or there was a bug in our release process somewhere).

Install on top the helm chart:

This phrase isn't really precise enough since there are 4 places you can get the helm chart from.

Helm repo at https://istio-release.storage.googleapis.com/charts
Helm repo at gcr.io/istio-release/charts
Helm chart from manifests/ in the released ./tar.gz such as https://github.com/istio/istio/releases/download/1.17.2/istio-1.17.2-linux-amd64.tar.gz
git pull https://github.com/istio/istio/ and using manifests/ --- THIS ONE IS WRONG

fwiw @howardjohn , this occurs with the officailly supported documentation:
https://istio.io/latest/docs/setup/install/helm/
I'm using this with argocd to deploy:
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: istio-base
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "2"
spec:
  project: default
  source:
    repoURL: https://istio-release.storage.googleapis.com/charts
    chart: base
    targetRevision: ~1.17.2
  destination:
    server: "https://kubernetes.default.svc"
    namespace: istio-system
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: istiod
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "3"
spec:
  syncPolicy:
    automated:
      selfHeal: true
  project: default
  source:
    repoURL: https://istio-release.storage.googleapis.com/charts
    chart: istiod
    targetRevision: ~1.17.2
    helm:
      values: |
        pilot.image: docker.io/istio/pilot:1.17.2
  destination:
    server: "https://kubernetes.default.svc"
    namespace: istio-system
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: istio-ingressgateway
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "4"
spec:
  syncPolicy:
    automated:
      selfHeal: true
  project: default
  source:
    repoURL: https://istio-release.storage.googleapis.com/charts
    chart: gateway
    targetRevision: ~1.17.2
  destination:
    server: "https://kubernetes.default.svc"
    namespace: istio-ingress

So option 1 produces this same problem, even IF he's using option 4 and is the wrong one.

If (1) produces that it's a big issue. Is it only 1.17.2? https://github.com/istio/istio/issues/44237#issuecomment-1499578780 was me trying and failing to reproduce it myself but that was 1.17.1. On my phone currently so it's hard to check but can later as well

istiod container while released with helm @v1.17.1 was scheduled to use the image gcr.io/istio-testing/pilot:latest running at version

@howardjohn  I've personally only tried 1.17.2, using the manual override mentioned resolved it for me so I haven't tried any other version I dont know about the OP though

FWIW, helm show values istio/istiod and looking at pilot shows this:
pilot:
  autoscaleEnabled: true
  autoscaleMin: 1
  autoscaleMax: 5
  replicaCount: 1
  rollingMaxSurge: 100%
  rollingMaxUnavailable: 25%

  hub: ""
  tag: ""
  variant: ""

  # Can be a full hub/image:tag
  image: pilot

by default if no tag is provided, docker resorts to "latest" however there is no latest, just some 1.17.2 / sha values (https://hub.docker.com/r/istio/pilot) .   I went back and I looked at my 2 nodes, and see the following:
gcr.io/istio-testing/pilot:latest                                                                                application/vnd.docker.distribution.manifest.list.v2+json sha256:7fb3972b580af9bca8145ca1539b7204b61395d0f124855aa697822644cfca6b 71.4 MiB  linux/amd64,linux/arm64                                                                                io.cri-containerd.image=managed
gcr.io/istio-testing/pilot@sha256:7fb3972b580af9bca8145ca1539b7204b61395d0f124855aa697822644cfca6b

and
docker.io/istio/pilot:1.17.2                                                                                application/v                                                                                io.cri-containerd.image=managed
docker.io/istio/pilot@sha256:04b21dec3b67c429340a03fc8dd2eebef91cd5081a229f7552ecc31a3b5bd403

the docker.io/istio/pilot:1.17.2 is the one currently running that works. however the previous node that istio tried to install on, has a diferent repository: gcr.io/istio-testing/pilot:latest
I don't see anything in the values file that would point to gcr.io, however it seems multiple people are having the wrong registry being used, and I doubt it's an ArgoCD thing (even thou @estevaofay is using it as well) because NO other image in my cluster pulls from the wrong repo when deployed via Argo.

$ helm template istio/istiod | rg image: | tail -n1
          image: "docker.io/istio/pilot:1.17.2"

$ helm template --repo https://istio-release.storage.googleapis.com/charts istiod | rg image: | tail -n1
          image: "docker.io/istio/pilot:1.17.2"

$ helm show values --repo https://istio-release.storage.googleapis.com/charts --version 1.17.2 istiod | toJson | gron | rg 'hub|tag|image'
json.global.hub = "docker.io/istio";
json.global.imagePullPolicy = "";
json.global.imagePullSecrets = [];
json.global.proxy.image = "proxyv2";
json.global.proxy_init.image = "proxyv2";
json.global.tag = "1.17.2";
json.pilot.hub = "";
json.pilot.image = "pilot";
json.pilot.tag = "";

Like you said I can't find a way to get to gcr.io/istio-testing (aside from git clone and using that, which is not supported). I would doubt Argo is doing something weird.
Note on the show values part they settings are just split between global and pilot

Huh, with Argo I can reproduce it!
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

argocd login <IP_ADDRESS>

kubectl apply -f manifests/charts/base/crds/crd-all.gen.yaml

kubectl create namespace istio-system
cat <<EOF | kubectl apply -f -
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: istiod
  namespace: argocd
spec:
  syncPolicy:
    automated:
      selfHeal: true
  project: default
  source:
    repoURL: https://istio-release.storage.googleapis.com/charts
    chart: istiod
    targetRevision: ~1.17.2
  destination:
    server: "https://kubernetes.default.svc"
    namespace: istio-system
EOF

@howardjohn something else I might add:
When I create my microservice helm charts I just usually have a pretty barebones structure for helm (created using helm create command)
This usually includes a templates folder, Chart.yaml, values.yaml and so on.
When I do a istio pull via helm like described a couple answer above, the istio helm chart comes with this files/gen-istio-cluster.yaml  file.
I found that ArgoCD is applying this file instead of generating manifests through the combination of templates + values.yaml + Chart.yaml
So when I updated values.yaml to use the correct tag, nothing happened on ArgoCD, but when I changed this gen-istio-cluster.yaml file, it did.
This might just be me not knowing Helm charts deeply enough to work with this specific scenario, but this is the first time I've seen this happen.
I thought I'd mention it to give more information to the debuggers

I figured it out (thanks to https://github.com/istio/istio/issues/44237#issuecomment-1505453120 mostly!). Its getting confused thinking it should use kustomize and not helm, the kustomize refers to the wrong image.
Simply putting a dummy helm value is enough to "fix" it:
cat <<EOF | kubectl apply -f -
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: istiod
  namespace: argocd
spec:
  syncPolicy:
    automated:
      selfHeal: true
  project: default
  source:
    repoURL: https://istio-release.storage.googleapis.com/charts
    chart: istiod
    targetRevision: ~1.17.2
    helm:
      values: |
        fake: bar
  destination:
    server: "https://kubernetes.default.svc"
    namespace: istio-system
EOF

At surface level this seems like possibly wrong behavior by Argocd. However, also partially on us for publishing the kustomize part. Will dig into it a bit more for next steps.
Thanks for all the info provided here !

Opened https://github.com/argoproj/argo-cd/issues/13210 against Argo.
For the time being, I recommend users just explicitly set some field under helm. Could be anything:
  source:
    repoURL: https://istio-release.storage.googleapis.com/charts
    chart: istiod
    targetRevision: ~1.17.2
    helm:
      version: "v3"

Loved this @howardjohn glad I could be of assistance. After reading the ArgoCD thread I understand the problem better!
Just for people reading this, I don't use the pattern described above to apply
source:
    repoURL: https://istio-release.storage.googleapis.com/charts
    chart: istiod
    targetRevision: ~1.17.2

I use ArgoCD's App of Apps pattern. This is why I "open" up the Helm chart and try to apply it like that. Here's a more detailed explanation of what I mean:
my file tree structure is the following
.
├── apps
│   ├── bootstrap
│   │   ├── Chart.yaml
│   │   ├── templates
│   │   │   ├── applications.yaml
│   │   │   └── namespaces.yaml
│   │   └── values.yaml
│   └── namespaces
│       ├── istio-system.yaml
│       ├── kustomization.yaml
├── charts
│   ├── istio-base
│   ├── istio-gateway
│   ├── istiod
│   │   ├── Chart.yaml
│   │   ├── README.md
│   │   ├── files
│   │   │   ├── gateway-injection-template.yaml
│   │   │   ├── gen-istio.yaml
│   │   │   ├── grpc-agent.yaml
│   │   │   ├── grpc-simple.yaml
│   │   │   └── injection-template.yaml
│   │   ├── kustomization.yaml
│   │   ├── templates
│   │   │   ├── NOTES.txt
│   │   │   ├── autoscale.yaml
│   │   │   ├── clusterrole.yaml
│   │   │   ├── clusterrolebinding.yaml
│   │   │   ├── configmap-jwks.yaml
│   │   │   ├── configmap.yaml
│   │   │   ├── deployment.yaml
│   │   │   ├── istiod-injector-configmap.yaml
│   │   │   ├── mutatingwebhook.yaml
│   │   │   ├── poddisruptionbudget.yaml
│   │   │   ├── reader-clusterrole.yaml
│   │   │   ├── reader-clusterrolebinding.yaml
│   │   │   ├── revision-tags.yaml
│   │   │   ├── role.yaml
│   │   │   ├── rolebinding.yaml
│   │   │   ├── service.yaml
│   │   │   ├── serviceaccount.yaml
│   │   │   ├── telemetryv2_1.13.yaml
│   │   │   ├── telemetryv2_1.14.yaml
│   │   │   ├── telemetryv2_1.15.yaml
│   │   │   ├── telemetryv2_1.16.yaml
│   │   │   ├── telemetryv2_1.17.yaml
│   │   │   └── validatingwebhookconfiguration.yaml
│   │   └── values.yaml

Under apps/bootstrap/templates/application.yaml
I have an ArgoCD Application descriptor that loops through all chart folders under charts including istio.
Here's how this ArgoCD Application manifest looks like before template rendering
{{- range $app := .Values.applications }}
{{- range $microservice := $app.microservices }}
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: {{ $microservice.name }}
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: {{ ($microservice.precedence | quote) | default ("5" | quote) }}
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: bootstrap
  source:
    repoURL: my-repo.git
    targetRevision: {{ $.Values.targetRevision }}
    path: charts/{{ $microservice.name }}
  destination:
    server: https://kubernetes.default.svc
    namespace: {{ ($microservice.namespace | default $app.namespace) | default "default" }}
  syncPolicy:
    automated:
      prune: {{ $microservice.prune | default true }}
      selfHeal: {{ $microservice.selfHeal | default true }}
{{- end }}
{{- end }}

So essentially I'm creating an App for each folder under charts (istiod, istio-gateway, istio base all included).

Here's the rendered out Application for istiod specifically
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: istiod
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "5"
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: bootstrap
  source:
    repoURL: my-repo.git
    targetRevision: my-branch
    path: charts/istiod
  destination:
    server: https://kubernetes.default.svc
    namespace: istio-system
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

So I'm not explicitly setting it as a Helm chart as @howardjohn pointed out in his manifest (wherein the bug lies)  but it still happens through my method which I still think applies

Ok we have fixed this issue on 1.16+ in the next patch releases (which are not out yet). In the meantime please follow https://github.com/istio/istio/issues/44237#issuecomment-1505911661 to explicitly declare things as "helm".
Thanks everyone!


Ensure that all ontologies are reachable

Define a CI job that polls all URLs in versions.yaml. Should run once a week or so and email on failure.

This would be awesome! Could it also send an email about new versions that come out?

Think that checking for new versions would be more work since not all ontologies host on the same website with some API to query for new versions.
I'll add the CI job this week. I already wrote similar code in the past and it should be quick.


404 routing for static export without exportPathMap

Resolves #5035
Thanks a billion to @timneutkens for holding my hand

Hello! Is there currently a workaround for this at the moment? I have updated to the latest version but instead of getting the custom designed 404 page, I am getting the default 404 page (as rendered from next/error) when I make a static export.

🤔 I'm on latest as well and my static exports do show my custom 404 component. Do you have a repo of your code? I could check it out!

Yeah, It is a private project for a client, I don't know if showing you the repo violates our NDA.
Anyways, I am currently handling the error pages with the hosting provider being used and it works for now.


Respect the loglevel for logging

This adds support for disabling console.log on CI and when
the loglevel asks for it.

I think it could be argued that disabling this during CI is not universally loved. Respecting the log level seems like a good idea to me.

@JoelEinbinder Do you agree with the latest changes? I don't know why CI is failing right now.


Removal of Statuses::characters_reserved_per_url?

This PR, removes the characters_reserved_per_url field on Statuses. I was relying on this field to calculate the correct number of allowed chars when the user is writing a toot. Is there a particular reason why this field is not being used anymore? The mastodon API still lists this property in the JSON schema..

Ah, probably it is a mistake...

Ok :) I will open a PR later today, I also have another change I'd like to add.


Proxy does not build on FreeBSD as of v1.27.0 release

As of v1.27.0, the cloud-sql-proxy fails to build on FreeBSD. It seems that github.com/hanwen/go-fuse does not work on this operating system. The build fails as follows:
# github.com/hanwen/go-fuse/v2/fuse
go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.1.0/fuse/types.go:550:2: undefined: Attr
go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.1.0/fuse/types.go:578:2: undefined: Attr
go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.1.0/fuse/api.go:224:41: undefined: GetAttrIn
go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.1.0/fuse/api.go:225:41: undefined: SetAttrIn
go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.1.0/fuse/api.go:228:39: undefined: MknodIn
go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.1.0/fuse/api.go:252:42: undefined: SetXAttrIn
go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.1.0/fuse/api.go:258:40: undefined: CreateIn
go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.1.0/fuse/api.go:260:38: undefined: ReadIn
go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.1.0/fuse/api.go:269:39: undefined: WriteIn
go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.1.0/fuse/api.go:278:41: undefined: ReadIn
go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.1.0/fuse/api.go:278:41: too many errors

Rolling back to v1.26.0 builds fine.

Thanks for the report @mhoran. I'm surprised that go-fuse doesn't support FreeBSD. Nonetheless, we'll put this behind a build constraint in the next release.

We will get this out in the next release.


Non generic batching

Do we even consider merging this as well? Or should I close it?

Do we even consider merging this as well? Or should I close it?

let's close it and just wait when @EivydasKoc comes back from vacation


MeshCentral Agent not working on Android 14

Hello everybody,
I am currently experiencing that the awesome MeshCentral Agent for Android crashes, when used on Android 14 devices. I can setup a server in the app, everything is fine. I can click on connect and see the device in MeshCentral, everything is fine. I try to access the desktop, allow everything on my phones and the app crashes. This occours on a Google Pixel 6 Pro running Android 14 as well as a Samsung A54 running Android 14. Devices running Android 13 are working perfectly fine with my server.
Is this behaviour known and maybe a bugfix rising somewhere, or is there any special trick or workaround I was unable to find?
Thanks in advance and best regards :-)

I've had the same issue last time I tried to use MC on my Pixel 6 Pro, I thought it might have been due to running Android 14 veesion of GrapheneOS so would be interested to see other replies on the issue, I will try it again and did in to the error logs

Duplicate of #24
Android 14 requires more permissions, so it currently just crashes, we have uploaded a new version to Google play and awaiting for them to approve it
In the mean time, you can build the app urself and generate an apk and install that, as the fix has already been implemented

Duplicate of #24
Android 14 requires more permissions, so it currently just crashes, we have uploaded a new version to Google play and awaiting for them to approve it
In the mean time, you can build the app urself and generate an apk and install that, as the fix has already been implemented

Thank you, I'm going to build the app now

Thanks, that worked perfectly fine for me. :-)

No worries, glad it works.
I will do a build myself soon, and also target older versions of android (as currently it needs 12=>) and update the apk file on the website and inside meshcentral, until Google play nice and release the update!

works my end too


Graphic auto resize

Graphic doesn't resize to screen size, per browser, mobile or desktop.

Changed the max-width of an image from a fixed width (850px) to 100% of its parent container.


Change type attribute to other to use with native esm type="module"

Native es modules needs type='module' to compile. babel-standalone need this field so I can't use both.
In Chrome Canary (64)

I'm not quite sure how you'd use both together... Can you elaborate on how it'd work? I don't know a lot about ES modules.

My use case is as follows: a react-based library uses ES6 export. Therefore it has to be imported within a

Actually it is also possible to skip ES6 import and parse it with Babel so all imports and exports are transpiled (and not really used, but at least the library has the same source code in standalone mode as in node.js use)

I just came across this same issue. Where I would like the contents of a