[a11y][iOS] VoiceOver announces unrelated widget after focused widget is removed from the widget tree

Steps to reproduce

Enable VoiceOver (via iOS settings app).
Navigate to sample code app.
Double tap the form field to focus it.
Enter some text and double tap the X button at the end of the form field to clear the form field.

Expected results
VoiceOver's announcements should stay anchored to the primary focus node (the form field, according to FocusManager).
Actual results
VoiceOver begins announcements from the top of the screen, at a widget which is not have primary focus.
Code sample
Code sample
import 'package:flutter/material.dart';

void main() async {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      home: MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  MyHomePage({Key? key, required this.title}) : super(key: key);
  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title, style: TextStyle(fontFamily: 'ProductSans')),
      ),
      body: Center(
        child: Column(
          children: [
            ClearableTextFormField(
              controller: TextEditingController(),
              focusNode: FocusNode(debugLabel: 'ClearableTextFormField'),
              labelText: 'Text Field 1',
            ),
          ],
        ),
      ),
    );
  }
}

/// Creates a [TextFormField] widget whose text can be cleared by clicking the
/// clear [Icon].
///
/// The clear [Icon] only appears if [TextFormField.text] is not empty.
/// Otherwise, it is hidden.
class ClearableTextFormField extends StatefulWidget {
  const ClearableTextFormField({
    required this.controller,
    required this.focusNode,
    required this.labelText,
  });
  final String labelText;
  final TextEditingController controller;
  final FocusNode focusNode;

  @override
  State<ClearableTextFormField> createState() => _ClearableTextFormFieldState();
}

class _ClearableTextFormFieldState extends State<ClearableTextFormField> {
  @override
  Widget build(BuildContext context) {
    return TextFormField(
      controller: widget.controller,
      focusNode: widget.focusNode,
      onChanged: (value) => setState(() {}),
      keyboardType: TextInputType.text,
      textCapitalization: TextCapitalization.sentences,
      decoration: InputDecoration(
        focusedBorder: UnderlineInputBorder(
          borderSide: BorderSide(),
        ),
        labelText: widget.labelText,
        suffixIcon: widget.controller.text.isEmpty
            ? null
            : IconButton(
                onPressed: () => _clearText(),
                icon: Icon(
                  Icons.clear,
                ),
              ),
      ),
    );
  }

  void _clearText() {
    widget.controller.clear();

    // // This call, when uncommented, has NO effect on the next widget announced by VoiceOver.
    // Future.delayed(Duration.zero, widget.focusNode.requestFocus);

    // This call only ever print "ClearableTextFormField", indicating that the
    // focus is correct.
    print(FocusManager.instance.primaryFocus?.debugLabel);

    // Rebuild to remove the icon button.
    setState(() {
      // // This call, when uncommented, has NO effect on the next widget announced by VoiceOver.
      // Future.delayed(Duration.zero, widget.focusNode.requestFocus);

      // This call only ever print "ClearableTextFormField", indicating that the
      // focus is correct.
      print(FocusManager.instance.primaryFocus?.debugLabel);
    });
  }
}

Screenshots or Video

Screenshots / Video demonstration
https://github.com/user-attachments/assets/054e41f6-007f-41b6-9bc0-3b05ddf6f67d

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[✓] Flutter (Channel google3, on macOS 14.7 darwin-x64, locale en)
    • Framework revision e7c993d7f9 (1 days ago), 2024-10-02T00:00:00.000
    • Engine revision bd44b58e32
    • Dart version 14b931c400

[✓] Android toolchain - develop for Android devices (Android SDK version Stable)
    • Android SDK at google3
    • Platform Stable, build-tools Stable
    • Java binary at: /Applications/Android Studio with Blaze Beta.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 21.0.3+-79915915-b509.11)

[✓] VS Code (version 1.93.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.86.0

[✓] Xcode - develop for iOS and macOS (Xcode 15.0)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A240d

[✓] Connected device (2 available)
    • Christian’s iPhone (mobile) • 00008101-9• ios        • iOS 17.2.1 21C66

Reproduced this issue on Flutter stable and master versions below. Some semi-similar cases:

https://github.com/flutter/flutter/issues/53022 (most likely issue)
https://github.com/flutter/flutter/issues/36910

flutter doctor (stable and master)
[✓] Flutter (Channel stable, 3.24.3, on macOS 15.0 24A335 darwin-x64, locale en-VN)
    • Flutter version 3.24.3 on channel stable at /Users/huynq/Documents/GitHub/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 2663184aa7 (3 weeks ago), 2024-09-11 16:27:48 -0500
    • Engine revision 36335019a8
    • Dart version 3.5.3
    • DevTools version 2.37.3

[!] Flutter (Channel master, 3.26.0-1.0.pre.353, on macOS 15.0 24A335 darwin-x64, locale en-VN)
    • Flutter version 3.26.0-1.0.pre.353 on channel master at /Users/huynq/Documents/GitHub/flutter_master
    ! Warning: `flutter` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/flutter, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/dart, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 389846308a (3 hours ago), 2024-10-03 21:52:22 -0400
    • Engine revision 66d397dff8
    • Dart version 3.6.0 (build 3.6.0-317.0.dev)
    • DevTools version 2.40.0-dev.2
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

More related discussion:
https://github.com/flutter/flutter/issues/59594

I think this is WAI, for 2 reason

keyboard focus and a11y focus is different, so a11y focus doesn't necessary need to follow the keyboard focus
Jumping the a11y focus to any place programmatically will be confusing for visually impaired users. In this case, the a11y focused item is removed. jumping to the textfield which is keyboard focused is equally confusing than jumping to any place on the screen since some users may not be able to see the screen and know about keyboard focus. Jumping to top of the screen while not ideal, but may be the best we can do.

I think best way forward is to design a UI that minimize adding/removing controls.

Clarifying on the last comment since we've gotten some questions from customers. This behavior is intended but modifiable. The FocusSemanticEvent API does allow manually setting the a11y focus. We recommend caution when using it to manipulate the a11y focus because it could end up breaking the users' expectation of how the a11y focus should behave.

I second on this behavior is intended,
I tested on the youtube app(which is not a flutter app) on android .
When clicking the close button to clear the text field, the a11y focus jumps to the top left node (navigation button) instead of the test field. Its behavior is same as this issue (jump to the top left).
The FocusSemanticEvent API is a last resort to manually modify a11y focus , but I strongly recommend not using it.
https://github.com/user-attachments/assets/f1ffaad3-4e5d-434f-b39e-4e799da3f670


Update APNS binary provider API from version 1 to 2, support APNS priority

Version 2 is the latest, documented at  https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/BinaryProviderAPI.html#//apple_ref/doc/uid/TP40008194-CH13-SW1
Also update the mock APNS server (https://github.com/uniqush/apns-simulator) to handle this
172     buffer := bytes.NewBuffer(dataBuffer[:0])
173     // command
174     binary.Write(buffer, binary.BigEndian, uint8(1)) // Should change this to uint8(2)
175     // transaction id
176     binary.Write(buffer, binary.BigEndian, mid)
177
178     // Expiry
179     binary.Write(buffer, binary.BigEndian, expiry)

in srv/apns/binary_api/processor.go
Benefits: This lets us add the 5th Priority field, to try to send messages immediately.

Fixed by #154


Examples playground instructions won't work in Windows

I'm trying to follow the steps for running the examples playground, but when running yarn on the "package" directory, it will fail when trying to create symlinks in Windows 10. The exact error is the following:

Updating symlinks for Android build...
Creating symlink to api E:\Development\Repositories\react-native-skia\package\scripts E:\Development\Repositories\react-native-skia\package
node:internal/fs/utils:344
    throw err;
    ^

Error: EEXIST: file already exists, symlink 'E:\Development\Repositories\react-native-skia\package\cpp\api' -> 'E:\Development\Repositories\react-native-skia\package\android\cpp\api'
    at Object.symlinkSync (node:fs:1651:3)
    at createSymlink (E:\Development\Repositories\react-native-skia\package\scripts\install-npm.js:8:6)
    at Object.<anonymous> (E:\Development\Repositories\react-native-skia\package\scripts\install-npm.js:16:1)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:79:12)
    at node:internal/main/run_main_module:17:47 {
  errno: -4075,
  syscall: 'symlink',
  code: 'EEXIST',
  path: 'E:\\Development\\Repositories\\react-native-skia\\package\\cpp\\api',
  dest: 'E:\\Development\\Repositories\\react-native-skia\\package\\android\\cpp\\api'

If I try to build the example regardless of this error, when running "npx react-native run-android" it will fail and complain about some source files missing, presumably because the symlink did not work. This was executed on a freshly cloned repository, so no previous build steps were run, but the destination link path mentioned in the error seems to be versioned in Github.
NOTE It seems like the library won't build on Windows either, even if I restrict it to build the android binaries only. I'm using the ninja binary that comes with the Android SDK cmake (v3.10). It seems like the build script is unable to create and enter the "out" folder in the cloned skia submodule.

I get the same error on macOS, running  yarn in package directory on 65a3c6676eab6ebe21bdd32d5ced838fc16649f0 leads to:
[4/4] 🔨  Building fresh packages...
$ yarn node scripts/install-npm.js
yarn node v1.22.17
Updating symlinks for Android build...
Creating symlink to api /Users/foo/source/react-native-skia/package/scripts /Users/foo/source/react-native-skia/package
internal/fs/utils.js:332
    throw err;
    ^

Error: EEXIST: file already exists, symlink '/Users/foo/source/react-native-skia/package/cpp/api' -> '/Users/foo/source/react-native-skia/package/android/cpp/api'
    at Object.symlinkSync (fs.js:1214:3)
    at createSymlink (/Users/foo/source/react-native-skia/package/scripts/install-npm.js:8:6)
    at Object.<anonymous> (/Users/foo/source/react-native-skia/package/scripts/install-npm.js:16:1)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:76:12)
    at internal/main/run_main_module.js:17:47 {
  errno: -17,
  syscall: 'symlink',
  code: 'EEXIST',
  path: '/Users/foo/source/react-native-skia/package/cpp/api',
  dest: '/Users/foo/source/react-native-skia/package/android/cpp/api'
}
error Command failed.
Exit code: 1

These should be fixed now. Feel free to reopen if needed.

These should be fixed now. Feel free to reopen if needed.

I'm facing the same issue on Windows, any solution?

I'm facing the same issue on Windows, any solution?


fix: allow layer flushes more often

As seen with the pgvector 0.7.0 index builds, we can receive large batches of images, leading to very large L0 layers in the range of 1GB. These large layers are produced because we are only able to roll the layer after we have witnessed two different Lsns in a single DataDirModification::commit. As the single Lsn batches of images can span over multiple DataDirModification lifespans, we will rarely get to write two different Lsns in a single put_batch currently.
The solution is to remember the TimelineWriterState instead of eagerly forgetting it until we really open the next layer or someone else flushes (while holding the write_guard).
Additional changes are:

test fixes to avoid "initdb image layer optimization" or ignoring initdb layers for assertion
test fix to ignore an image layer, and how to stringify it now in #7986
now we only warn if an oversized layer is twice the checkpoint_distance now in #7985

Cc: #7197 because small checkpoint_distance will now trigger the "initdb image layer optimization"

test_actually_duplicated_l1: release, debug

This test failure is rather interesting; it seems with low enough checkpoint_distance this new version will roll the layer before the wal is ingested, and so is able to perform the "initdb image layer optimization", or #5863.

test_fast_growing_tenant[absolute]: release, debug

This is an instance of the same problem, but now it does seem like the initdb is split into multiple image layers!

test_tenant_s3_restore: release, debug

This was most complicated so far, commented here: https://github.com/neondatabase/neon/issues/7197#issuecomment-2147915819

The build status is red due ECR images becoming outdated. I assume we don't merge this without discussion, so not re-running the related jobs right now.
Discussion: https://neondb.slack.com/archives/C059ZC138NR/p1717583177302419

Manual testing with gin index build: https://github.com/neondatabase/cloud/issues/13759#issuecomment-2152938601

Testing to see how long did the gin test on main take, on the branch earlier it was ~16s per each of three tests.

Failures on Postgres 15

test_location_conf_churn[2]: release

Vectored get validation panic while shutting down.


Applied Visual Design: Make Motion More Natural Using a Bezier Curve TYPO

Describe your problem and how to reproduce it:
The text reads: "Prior challenges covered the linear and ease-out cubic Bezier curves, however...."
but it should read: Prior challenges covered the linear and ease-out curves, however..."
Add a Link to the page with the problem:
https://www.freecodecamp.org/learn/responsive-web-design/applied-visual-design/make-motion-more-natural-using-a-bezier-curve
Recommended fix, suggestions (how would you update it?):
by deleting cubi

c Bezier
If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box):

It might not seem apparent, but animation-timing-function uses a cubic Bezier calculation even for pre-defined values such as linear and ease-out, according to [MDN]

The non-step keyword values (ease, linear, ease-in-out, etc.) each represent cubic Bézier curve with fixed four point values, with the cubic-bezier() function value allowing for a non-predefined value.

So it means that the text is indeed correct and it should not be changed. Thanks very much for your answer :+1:


Problem with model2json

As you provided a python script. ./tool/model2json, to convert model to json file. When i am running this script with my model i am getting error:
TypeError: write() argument must be str, not bytes
Getting this error make sense because, how can you  write bytes to a file that is opened in string mode. At line
model = base64.b64encode(bytes(open(sys.argv[3], 'rb').read()))
You are reading it in bytes but in line
with open(sys.argv1, 'w') as fo:
you are opening file in string mode and in line
fo.write(model)
You are writing bytes to string.
May be i am missing something, help me out with this.

This is probably because you are using python 3 which is more restrictive on byte/string conversions.
Add .decode() to the end of
model = base64.b64encode(bytes(open(sys.argv[3], 'rb').read()))
This fixed it for me as it explicitly converts it into a string.


luci-app-commands: do not escape pipe on cmd line

Signed-off-by: Andi Peh<EMAIL_ADDRESS>

Thanks for your report.
Done with https://github.com/openwrt/luci/commit/6d9a0488d65413743c7bc1d0bff5fef6b9713b49


prevent Moving an item / locked an Item

Hi,
Can I do somehow to prevent any item to draggin/moving?
For example, I can't moving the second item only others.
Thanks,
Gabor

Hi @fehernyul
In the latest version of the library, we’ve introduced the lockedItem property, which allows you to specify a list of items that cannot be moved or reordered, and let us know if you encounter any further issues.


Add guidance on why we use tools, and the alternative methods needs to be added.

Keeping the role of each tool in perspective is important so we don’t get lost in the testing of each other them but lose sight of objectives.
E.g. Recon-ng is great and was super interesting. An overview of why, how, and how it’s been done in the past - the big picture - would have made it easier to explore and understand where it fits in the suite of possibilities.
Basic intro to networks and how nmap works would have been helpful to frame the skill. We spent a lot of time looking at developing profiles, which was cool, but didn’t position us to know why, when, and the basic approach to do the scans.
See: the overview overhaul branch for work on this

E.G. "While already well-stated, it may make sense that cracking a password is an unusal demonstration to be used when there is stark denial of the need for strong passwords and when there is consent – there are other ways of launching effective discussions on passwords when the host organization is more cooperative (for example playing password strength games with staff during or after interviews)"


NIFI-7586 Add socket-level timeout properties for CassandraSessionProvider

https://issues.apache.org/jira/browse/NIFI-7586
In CassandraSesionProvider added properties to set socket-level read timeout and connect timeout. In QueryCassandra when writing flowfile to the sesion it's done on the raw OutputStream. Wrapped it in a BufferedOutputStream for better performance.
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

[x] Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

[x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] Have you verified that the full build is successful on JDK 8?
[ ] Have you verified that the full build is successful on JDK 11?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI for build issues and submit an update to your PR as soon as possible.

After changing the timeouts, I get the following errors from QueryCassandra / PutCassandraQL:
ERROR [Timer-Driven Process Thread-10] o.a.n.p.cassandra.QueryCassandra QueryCassandra[id=01ad5a7c-0173-1000-7fb3-a34af5274655] No host in the Cassandra cluster can be contacted successfully to execute this query: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (no host was tried)

com.datastax.driver.core.exceptions.DriverInternalError: Unexpected exception thrown

Did it work for you?

@turcsanyip
Thanks for finding this. It turns out there's been a bug in CassandraSessionProvider for a long time now.
Not related to this change so I opened a new ticket and will fix it in a subsequent PR: https://issues.apache.org/jira/browse/NIFI-7590


3d Textured volume plot fails on Windows

rmid: 47rmsubmitter: Kathleen Bonnellrmsubmitdate: 06/02/2010 01:52 pm Message is "Volume Rendering based on 3D textures is not supported on your GPU". Got this on a 32 bit VM running XP SP3, using the VMWare SVGA II driver.On the host system, a 64 bit XP SP3, with Nvidia Quadro FX 8700M, On my desktop system, also 32 bit XP SP3 with ATI Radeon X600 graphics card, Ican draw the 3D textured volume plot, but I get the GPU message when I try to savethe window (NON Screen Capture). This used to work before the switch to glew.
-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.
Ticket number: 166
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: 3d Textured volume plot fails on Windows
Assigned to: Tom Fogal
Category: -
Target version: -
Author: Cyrus Harrison
Start: 06/21/2010
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:40 pm
Updated: 06/22/2010 07:12 pm
Likelihood: 3 - Occasional
Severity: 2 - Minor Irritation
Found in version: 2.0.0
Impact:
Expected Use:
OS: All
Support Group: Any
Description:
rmid: 47rmsubmitter: Kathleen Bonnellrmsubmitdate: 06/02/2010 01:52 pm Message is "Volume Rendering based on 3D textures is not supported on your GPU". Got this on a 32 bit VM running XP SP3, using the VMWare SVGA II driver.On the host system, a 64 bit XP SP3, with Nvidia Quadro FX 8700M, On my desktop system, also 32 bit XP SP3 with ATI Radeon X600 graphics card, Ican draw the 3D textured volume plot, but I get the GPU message when I try to savethe window (NON Screen Capture). This used to work before the switch to glew.
Comments:
Win32 is missing all extensions and reports OpenGL 1.1 or something absurd. This seems to only happen when dynamically loading the function pointers.Few ideas:A good way to do the latter would be to fix GLEW_STATIC and just use it. Just fixing bug subject. If possible - a high priority should be placed on this for 2.0.2

Closing due to the fact that Visit no longer has a 3D texturing option for volume plot.


Path parameters in "Path Item Object" not correctly validated.

Describe the bug
Path parameters in "Path Item Object" not correctly validated.
To Reproduce
I tested a schema like the one below, which I believe is a valid one, but the library validation complains about path parameter 'pathParam' in path '/path/{pathParam}' being expected but undefined (code: 124)
(...)
/path/{pathParam}
  parameters:
    - name: pathParam
      in: path
      required: true
      description: A path parameter
      schema:
        type: string
  get:
(...)

Expected behavior
Expected that path parameters can be set in "Path Item Object" and optionally overridden in "Operation Object".

Did you miss the colon at the end of /path/{pathParam} or is it only in your report?
Otherwise, what if you add '/' at the end or a fixed path fragment?

Hi, sorry about that, the missing colon is a typo in the report only. I also tried with /path/{pathParam}/: and got the same result. Thanks for looking into this.

This is the relevant stack trace:
	at org.openapi4j.parser.validation.v3.OpenApi3Validator.validate(OpenApi3Validator.java:28)
	at org.openapi4j.parser.OpenApi3Parser.parse(OpenApi3Parser.java:41)
	at org.openapi4j.parser.OpenApi3Parser.parse(OpenApi3Parser.java:17)
	at org.openapi4j.parser.OpenApiParser.parse(OpenApiParser.java:53)

using  openapi-operation-validator version 1.0.1

Thanks for the further details. Can you upgrade to 1.0.3? This should be fixed in 1.0.2.

works fine now, thanks!


Trap changes to visioneval.cnf when opening a model with previous results

[This issue requests an internal change to VEModel to compare visioneval.cnf with the parameters in an existing previous model run. See issue #11 for how to manage that in the user interface.]
Need to identify results and outputs as "Obsolete" or "Out of Date" if they are older than the model configuration files (scripts, configurations, inputs, etc.).
Get a "latest modification date" by scanning file stats for the model file tree (other than results or outputs) and compare to modification date on the results folder tree. If the latter is older than the former, the results should be reported as "Out of Date".
When running a model with any "Out of Date" results, we do not just "continue" but rather give the user a warning that they must specifically name "continue", "update", "save" or "reset". If they choose "update", the results/outputs tree is updated to "now" and each stage (and its dependents) that remains in a status other than "Run Complete" will get re-run. Choosing "continue" if there are out of date stages will do a "reset" after giving the user a warning and opportunity to abort.
Could get more elaborate by looking at the actual model structural files on a file-by-file basis for each stage (so we can mark just certain individual stages as "Out of Date").

Done along with #11


The scene data is not accesed in google drive now because to many peple have downloaded it

When I try to download 3dllm_final_scene_data_blip_v1.zip, it returns:
(base) lhj@mac:/data/pointcloud/3dllm$ gdown https://drive.google.com/uc?id=118JSjS1nl-1v87wC2oTxEmQzSSyCIBXM
Access denied with the following error:

        Too many users have viewed or downloaded this file recently. Please
        try accessing the file again later. If the file you are trying to
        access is particularly large or is shared with many people, it may
        take up to 24 hours to be able to view or download the file. If you
        still can't access a file after 24 hours, contact your domain
        administrator.

You may still be able to access the file from the browser:

         https://drive.google.com/uc?id=118JSjS1nl-1v87wC2oTxEmQzSSyCIBXM

Could you please upload this big file to Baiduyun or OneDrive?

make a copy in your own google drive and download that copy

Same issue. Could you upload this file to huggingface?

make a copy in your own google drive and download that copy

It does allow the download to proceed for a longer time (compared to not making a copy). However it fails at about 80% progress.
Could you re-open the issue?

We are transferring the dataset to Huggingface, which may take several days. Sorry for the inconvenience

Huggingface: https://huggingface.co/datasets/ShuhongZheng/3D-LLM

@evelinehong there are issues with two of the archives shared in huggingface i.e. voxelized_features_sam_nonzero_preprocess.zip.ab and voxelized_features_sam_nonzero_preprocess.zip.ac. Getting the following error when I am trying to uncompress it:
7z x voxelized_features_sam_nonzero_preprocess.zip.ab

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,20 CPUs Intel(R) Core(TM) i9-10900X CPU @ 3.70GHz (50657),ASM,AES-NI)

Scanning the drive for archives:
1 file,<PHONE_NUMBER>0 bytes (40 GiB)

Extracting archive: voxelized_features_sam_nonzero_preprocess.zip.ab
ERROR: voxelized_features_sam_nonzero_preprocess.zip.ab
Can not open the file as archive

Can't open as archive: 1
Files: 0
Size:       0
Compressed: 0


docs(cdk-experimental/menu): add examples to menu documentation

I'm not 100% sure if I connected the examples with menu.md correctly. PTAL.

@jelbourn feedback should be addressed.

@jelbourn no problem.
Hope your vacation was good.


Add LangChain Support to RAG Agent

name: Pull Request
about: Create a pull request
Description

Integration of LangChain Knowledge:
Added the necessary components to support LangChain knowledge within the RAG agent.

Dynamic Backend Selection:
Implemented logic in the knowledge-bank to determine the backend engine (either LlamaIndex or LangChain) based on the knowledge-config imported module.

Refactor of LlamaIndexAgent:
The original LlamaIndexAgent has been renamed to RAG-Agent, allowing the same RAG agent to utilize knowledge from both backend engines seamlessly.

Checklist
Please check the following items before code is ready to be reviewed.

[x]  Code has passed all tests
[x]  Docstrings have been added/updated in Google Style
[ ]  Documentation has been updated
[x]  Code is ready for review

Thanks for your contribution, we will review this PR as soon as possible.

@cmgzn Please resolve the conflict. @ZiTao-Li @FredericW @xieyxclack Please check this PR


Istio sidecar not allowing connection to database

Describe the bug
Trying to connect to a Postgres database running inside Istio and kubernetes from a service inside istio, both with sidecars. Instead of allowing the connection the sidecar logs show:
[15][warning][upstream] external/envoy/source/common/config/grpc_mux_impl.cc:240] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers

Expected behavior
They should be able to stablish a connection.
Steps to reproduce the bug

Deploy a postgres database + service
Deploy a service that connects to the database

Version
ISTIO:
Version: 1.0.2
GitRevision: d639408fded355fb906ef2a1f9e8ffddc24c3d64
User: root@66ce69d4a51e
Hub: gcr.io/istio-release
GolangVersion: go1.10.1
BuildStatus: Clean
KUBERNETES: (v1.11)
Client Version: version.Info{Major:"1", Minor:"12+", GitVersion:"v1.12.0-rc.1", GitCommit:"3e4aee86dfaf933f03e052859c0a1f52704d4fef", GitTreeState:"clean", BuildDate:"2018-09-18T21:08:06Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T17:53:03Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Installation
Using helm with gateways.enabled=false & tracing.enabled=true
Environment
Kubernetes deployed in DigitalOcean
NOTES

Only works as expected if I deactivate the sidecar using the sidecar.istio.io/inject: "false" annotation on BOTH deployments work
I know I have to store passwords as secrets for production

Deployment files
Postgres database:
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-config
  namespace: app
  labels:
    app: postgres
data:
  POSTGRES_DB: postgres
  POSTGRES_USER: postgres
  POSTGRES_PASSWORD: mysecretpassword
---
kind: PersistentVolume
apiVersion: v1
metadata:
  name: postgres-pv-volume
  namespace: app
  labels:
    type: local
    app: postgres
spec:
  storageClassName: manual
  capacity:
    storage: 500Mi
  accessModes:
  - ReadWriteMany
  hostPath:
    path: "/mnt/data"
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: postgres-pv-claim
  namespace: app
  labels:
    app: postgres
spec:
  storageClassName: manual
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 500Mi
---
apiVersion: v1
kind: Service
metadata:
  name: postgres
  namespace: app
  labels:
    app: postgres
spec:
  ports:
  - port: 5432
    name: db
    # protocol: TCP
  selector:
    app: postgres
  # clusterIP: None
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: postgres-deployment
  namespace: app
  labels:
    app: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      # annotations:
      #   sidecar.istio.io/inject: "false"
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:10.4
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 5432
          name: db
          # protocol: TCP
        livenessProbe:
          exec:
            command:
            - pg_isready
            - -U
            - postgres
          initialDelaySeconds: 30
          timeoutSeconds: 3
        readinessProbe:
          exec:
            command:
            - pg_isready
            - -U
            - postgres
          initialDelaySeconds: 30
          timeoutSeconds: 3
        envFrom:
        - configMapRef:
            name: postgres-config
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: postgredb
      volumes:
      - name: postgredb
        persistentVolumeClaim:
          claimName: postgres-pv-claim

Service that connects to the databse:
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: pgservice-config
  namespace: app
  labels:
    app: pgservice
data:
  POSTGRESQL_CONNECTION: jdbc:postgresql://postgres:5432/postgres
  POSTGRESQL_USER: postgres
  POSTGRESQL_PASSWORD: mysecretpassword
---
apiVersion: v1
kind: Service
metadata:
  name: pgservice
  namespace: app
  labels:
    app: pgservice
spec:
  type: ClusterIP
  selector:
    app: pgservice
  ports:
  - port: 8080
    name: http
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pgservice-deployment
  namespace: app
  labels:
    app: pgservice
spec:
  replicas: 1
  selector:
    matchLabels:
      app: pgservice
  template:
    metadata:
      # annotations:
      #   sidecar.istio.io/inject: "false"
      labels:
        app: pgservice
    spec:
      initContainers:
      - name: check-db-ready
        image: postgres:10.4
        command: ['sh', '-c',
                  'until pg_isready -h postgres -p 5432;
                do echo waiting for database; sleep 2; done;']
      - name: exec-db-migration
        image: registry.gitlab.com/registry/pgmigration:latest
        imagePullPolicy: Always
        envFrom:
        - configMapRef:
            name: pgmigration-config
      containers:
      - name: pgservice
        image: registry.gitlab.com/registry/pgservice:latest
        imagePullPolicy: Always
        envFrom:
        - configMapRef:
            name: pgservice-config
        ports:
        - containerPort: 8080
          name: http
      imagePullSecrets:
      - name: regcred

I've got a PostgreSQL database and a service working with both the postgresql pod and the service deployed with sidecars and mutual-tls enabled between the two sidecars. In your service definition for PostgreSQL, you have ClusterIP commented out. What IP does "postgresql" resolve to when you try to connect to it from the service? If it's a pod IP and not a cluster IP, it's my understanding Istio will block this traffic. The service would need to talk to PostgreSQL over a ClusterIP.

Hi @geauxvirtual ,
I commented this line to show that I already tried that option. If I am not mistaken, if I don't include the type of service kubernetes defaults to CluterIP anyway.
Just to make sure, I un-commented the line and tried again and I still see the message error in the istio sidecar:
[2018-10-11 12:58:41.173][15][warning][upstream] external/envoy/source/common/config/grpc_mux_impl.cc:240] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers

I removed that comment following this conversation in google groups. They propose an example at this link. As you see, the example does not have the ClusterIP line, that is why I tried removing the ClusterIP line.
Do you have any special policies in place to make this work? What version of Istio are you running?

Using Istio 1.0.1. I have  a policy to enable Mutual TLS on port 5432 for the postgresql service, but I didn't have any issues connecting before enabling Mutual TLS either.
Can you exec into the istio-proxy container injected into your service and see what IP nslookup is returning for the postgres service you are trying to connect to?

Having the same issue. When the sidecar is injected successfully into my pod, the pod is unable to reach my Cassandra DB Instance.

Did anybody find a fix for this? I cannot connect to my Datastore database while using GKE with Istio.

In this case, I recommend to add below object.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: postgres
namespace: app
spec:
host: postgres
trafficPolicy:
tls:
mode: ISTIO_MUTUAL

@herasoo this is unindented, correct?

This is my k8's yaml configuration for "my-app" that requires to connect to Datastore on port (5432) and RabbitMQ on port (5672)
`apiVersion: v1
kind: Service
metadata:
name: myapp-service
labels:
app: myapp-service
spec:
ports:

name: rabbitmq
protocol: TCP
port: 5672
name: datastore
protocol: TCP
port: 5432
targetPort: 5432
type: NodePort
selector:
app: pbbarcode-pod

apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: myapp
image: eu.gcr.io//myapp:latest
imagePullPolicy: Always
ports:
- containerPort: 5672
- containerPort: 5432
env:
- name: MY_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
lifecycle:
preStop:
exec:
command: ["python3", "graceful_termination.py"]
volumeMounts:
# Name of root folder where filestore is mounted
- mountPath: Filestore/
name: mypvc
nodeSelector:
Focus: myapp
volumes:

name: mypvc
persistentVolumeClaim:
Name of volume claim created for Filestore
claimName: fileserver-claim
readOnly: false
restartPolicy: Never

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: myapp
spec:
host: myapp
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: myapp
spec:
hosts:

myapp.myapp-service.default.svc.cluster.local
ports:
number: 4369
name: epmd
protocol: TCP
number: 5672
name: amqp
protocol: TCP
number: 15672
name: http
protocol: HTTP
number: 25672
name: inter-node
protocol: TCP
number: 5432
name: database
protocol: TCP

apiVersion: "authentication.istio.io/v1alpha1"
kind: Policy
metadata:
name: myapp
spec:
targets:

name: myapp
peers:
mtls: {}`

What am I missing since this does not work?

This is my yaml file to run myapp which requires Datastore (port: 5432) and RabbitMQ (port: 5672)
`
apiVersion: v1
kind: Service
metadata:
name: myapp-service
labels:
app: myapp-service
spec:
ports:

name: rabbitmq
protocol: TCP
port: 5672
name: datastore
protocol: TCP
port: 5432
targetPort: 5432
type: NodePort
selector:
app: myapp-pod

apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: myapp
image: eu.gcr.io//myapp:latest
imagePullPolicy: Always
ports:
- containerPort: 5672
- containerPort: 5432
env:
- name: MY_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
lifecycle:
preStop:
exec:
command: ["python3", "graceful_termination.py"]
volumeMounts:
- mountPath: Filestore/
name: mypvc
nodeSelector:
Focus: myapp
volumes:

name: mypvc
persistentVolumeClaim:
claimName: fileserver-claim
readOnly: false
restartPolicy: Never

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: myapp
spec:
host: myapp
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: myapp
spec:
hosts:

myapp.myapp-service.default.svc.cluster.local
ports:
number: 4369
name: epmd
protocol: TCP
number: 5672
name: amqp
protocol: TCP
number: 15672
name: http
protocol: HTTP
number: 25672
name: inter-node
protocol: TCP
number: 5432
name: database
protocol: TCP

apiVersion: "authentication.istio.io/v1alpha1"
kind: Policy
metadata:
name: myapp
spec:
targets:

name: myapp
peers:
mtls: {}
`

I get this traceback:

Traceback (most recent call last):
File "pbbarcode.py", line 22, in
key = client.allocate_ids(client.key('analysis_and_barcodes'), 1)[0]
File "/env/lib/python3.7/site-packages/google/cloud/datastore/client.py", line 509, in allocate_ids
incomplete_key.project, incomplete_key_pbs
File "/env/lib/python3.7/site-packages/google/cloud/datastore_v1/gapic/datastore_client.py", line 633, in allocate_ids
request, retry=retry, timeout=timeout, metadata=metadata
File "/env/lib/python3.7/site-packages/google/api_core/gapic_v1/method.py", line 143, in call
return wrapped_func(*args, **kwargs)
File "/env/lib/python3.7/site-packages/google/api_core/retry.py", line 270, in retry_wrapped_func
on_error=on_error,
File "/env/lib/python3.7/site-packages/google/api_core/retry.py", line 179, in retry_target
return target()
File "/env/lib/python3.7/site-packages/google/api_core/timeout.py", line 214, in func_with_timeout
return func(*args, **kwargs)
File "/env/lib/python3.7/site-packages/google/api_core/grpc_helpers.py", line 59, in error_remapped_callable
six.raise_from(exceptions.from_grpc_error(exc), exc)
File "", line 3, in raise_from
google.api_core.exceptions.ServiceUnavailable: 503 Connect Failed

Should't port names in Service match https://istio.io/docs/setup/kubernetes/additional-setup/requirements/ ?

We made some bug fixes in this area in 1.3: https://istio.io/news/2019/announcing-1.3/#traffic-management
1.1 is no longer supported: https://istio.io/blog/2019/announcing-1.1-eol/
Please try on recent versions, if you do see the same issues please post all of your config and get config dumps: https://github.com/istio/istio/wiki/Troubleshooting-Istio#collecting-information-2


Ability to delete a volunteer

I don't see a way to delete a volunteer and their email address.

This may be related to #510.

@glittle Yes, original issue was #353, closing as dupe. Thanks!


Implement Weaviate

weaviate.io

Would be really up to integrate it:

It's open-source
Their three modes of search (see screenshot) are fabulous and I think Embedbase should integrate all three of them eventually

@hotkartoffel feel free to


update umeed version

Umee v4.1.0 Upgrade

What's the ETA on this upgrade?

Tue Feb 28 2023 approx 1530 UTC


Define case study from TenneT point of view

Desired time period: 2022
Objective of this work-item is to define and acquire the dataset relevant for the TenneT use case.

Measured load of 2022 of the connection points of Middenmeer

Liander: 6 trafo's connected to us
0 to other customers

Measured (or calculated) reactive power

Weather forecasts at different lead times

Provide context information on how customer+DSO forecasts are used at TSO for grid safety analyses and redispatch decissions (@Sjoerd)

Perspective is to see compare the pure-tennet-info forecasts with using additional data available from the DSO/customers.
Scope: only consider this substation, not neighboring substations due to data sharing limitations during the POC phase.

From TenneT side we would like to forecast active power for station Middenmeer as good as possible with few data, possibly with use of machine learning. Having few data about installed power in DSO grids is a real-life situation for TenneT, therefore we aim to investigate this.

TenneT would prefer to use the measurement data of Alliander on the connection points.

I am closing this issue, since it has been showing no progress for the last three months. I am going to open a new issue related to this topic. The new issue will correspond better with what we currently need to work on to make progress towards the PoC demonstrator deliverable.

Has been superseded by: https://github.com/alliander-opensource/AIFES/issues/41


[5.9-20230510][Dynamic Casting] Use old boxing semantics for pre-Fall-2023 apps

For Apple platforms, enable the new stricter boxing semantics only for apps built against the Fall 2023 or later SDK. This avoids breaking apps that relied on the old behavior and have not been updated since then.
Risk: Low. Adds a version check to ensure that pre-existing apps continue to see the old behavior.
Cherry-picked from #66350
Reviewed by @mikeash
Resolves rdar://109941470

@swift-ci Please test


Update intel-haxm to 6.1.1,19:94

👋  Thanks for maintaining this project guys 😍
After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

👋 Thanks for maintaining this project guys 😍

You're welcome.


404

If you are having trouble using the site:

What browser and version are you using? Safari.
What is the URL of the problem? Codalab is an open source project, we may not be supporting the instance you are using!

The official link which leads to our competition, which I believe is specific to the participants so I do not want to share it here.

I get a 404, with the following error message:
"Could not find the page you requested.
If you are the challenge organizer and this URL previously pointed to a valid competition and it is now missing please contact us at<EMAIL_ADDRESS>for more information.
If this is an error, please file a bug report. For more information about Codabench, check out the wiki."
Comp: 4430.
I still have a try left, and would like to be able to use it!

Hello, are you logged into the site ? This error can show if you are not logged in.

This competition is private, login to be able to see it
https://www.codabench.org/competitions/4430/


Fix simple typo in generate_ssl_imagenet.sh

delete '}' in line 44.

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
📝 Please visit https://cla.developers.google.com/ to sign.
Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.
What to do if you already signed the CLA
Individual signers

It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ Googlers: Go here for more info.

@googlebot I signed it!

Hi,
Thanks for finding a mistake and making a pull request.
Could you please limit your pull request to only changes in generate_ssl_imagenet.sh ?
Right now it contains a lot of other files as well.
Thanks,
Alex

sorry, just my mistake. Thank you!


Incorrect timeout behaviour given overflowing threads pools

I encountered multiple different issues regarding timeouts not firing when
the main thread pool and/or its queues are full or busy for a long time.
In most cases issues cause timeouts to either happen with a delay or never happen
at all. It did affect real running code as soon as some RPC hanging request
on one of the code paths was encountered. It quickly filled up the thread
pools and prevented anything else from being executed grinding app to a halt.
Here are some reproducible scenarios:
package net.jodah.failsafe;

import net.jodah.failsafe.util.concurrent.Scheduler;
import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.JUnitCore;

import java.time.Duration;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.CompletionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.SynchronousQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

/** Several related failures preventing timeouts caused by an overflowing thread pool or its queue. */
public class ThreadingTest {

    public static void main(String[] args) {
        JUnitCore.main("net.jodah.failsafe.ThreadingTest");
    }

    /**
     * While the thread pool is full, no timeout-based cancellations are executed as they stay in the queue.
     * We schedule two tasks, each schedule a timeout, both timeouts get stuck in queue until one of the tasks
     * is not finished.
     */
    @Test(timeout = 60_000)
    public void test01_NoTimeout_FullThreadPool() throws Exception {
        ExecutorService executorService = new ThreadPoolExecutor(
                2, 2, 1, TimeUnit.MINUTES, new LinkedBlockingQueue<>(),
                r -> new Thread(r, "test01_NoTimeout_FullThreadPool@" + r.hashCode()));
        FailsafeExecutor<?> failsafe = Failsafe.with(Timeout.of(Duration.ofSeconds(1)).withCancel(true))
                .with(executorService);
        CompletableFuture<?> firstTask = failsafe.runAsync(ctx -> Thread.sleep(Long.MAX_VALUE)); // never finishes
        CompletableFuture<?> secondTask = failsafe.runAsync(ctx -> Thread.sleep(TimeUnit.SECONDS.toMillis(2)));
        try {
            secondTask.join(); // both tasks keep the pool busy, so it's not possible to execute cancellation for any
            Assert.fail(); // as second task was never cancelled it finishes successfully
        } catch (CompletionException e) {
            Assert.assertTrue(e.getCause() instanceof TimeoutExceededException);
        }
        Thread.sleep(TimeUnit.SECONDS.toMillis(1)); // second task finished, now the first task is cancelled
        Assert.assertTrue(firstTask.isDone()); // first task should have been cancelled by now
    }

    /**
     * When main thread pool and its queue are full, no timeout-based cancellation could be scheduled for execution.
     * Contrary to the previous test even after one of the tasks has finished, second one would not get cancelled.
     */
    @Test(timeout = 60_000)
    public void test02_NoTimeout_FullQueue() throws Exception {
        ExecutorService executorService = new ThreadPoolExecutor(
                2, 2, 1, TimeUnit.MINUTES, new SynchronousQueue<>(),
                r -> new Thread(r, "test02_NoTimeout_FullQueue@" + r.hashCode()));
        FailsafeExecutor<?> failsafe = Failsafe.with(Timeout.of(Duration.ofSeconds(1)).withCancel(true))
                .with(executorService);
        CompletableFuture<?> firstTask = failsafe.runAsync(ctx -> Thread.sleep(Long.MAX_VALUE)); // never finishes
        CompletableFuture<?> secondTask = failsafe.runAsync(ctx -> Thread.sleep(TimeUnit.SECONDS.toMillis(2)));
        try {
            secondTask.join(); // we fail to schedule timeout cancellations, so none tasks will ever be interrupted
            Assert.fail(); // as second task was never cancelled it finishes successfully
        } catch (CompletionException e) {
            Assert.assertTrue(e.getCause() instanceof TimeoutExceededException);
        }
        Thread.sleep(TimeUnit.SECONDS.toMillis(1)); // give it some time to pick up, just in case
        Assert.assertTrue(firstTask.isDone()); // we failed to schedule cancellation, so first task would never cancel
    }

    /**
     * Naive fix that executes cancellation on the scheduled thread pool instead of delegating it back to the main.
     * This is the only test that passes out of the box.
     */
    @Test(timeout = 60_000)
    public void test03_NaiveFix_ExecuteOnScheduledThreadPool() throws Exception {
        ExecutorService executorService = new ThreadPoolExecutor(
                1, 1, 1, TimeUnit.MINUTES, new SynchronousQueue<>(),
                r -> new Thread(r, "test02_NaiveFix_ExecuteOnScheduledThreadPool"));
        Scheduler delegatingScheduler = Scheduler.of(executorService);
        ScheduledExecutorService scheduledExecutorService = Executors.newSingleThreadScheduledExecutor(
                r -> new Thread(r, "test02_NoTimeout_FullQueue-scheduled@" + r.hashCode()));
        FailsafeExecutor<?> failsafe = Failsafe.with(Timeout.of(Duration.ofSeconds(1)).withCancel(true))
                .with((callable, delay, unit) -> {
                    if (delay == 0) {
                        return delegatingScheduler.schedule(callable, delay, unit);
                    } else {
                        // Direct execution to never fail to execute TimeoutExecutor.timeoutFuture
                        return scheduledExecutorService.schedule(callable, delay, unit);
                    }
                });
        CompletableFuture<?> firstTask = failsafe.runAsync(ctx -> {
            System.out.println("Thread: " + Thread.currentThread().getName());
            Thread.sleep(Long.MAX_VALUE);
        });
        try {
            firstTask.join();
            Assert.fail();
        } catch (CompletionException e) {
            Assert.assertTrue(e.getCause() instanceof TimeoutExceededException);
        }
    }

    /**
     * Naive fix does not handle retry policy well. Retry policy executes directly, avoiding the scheduler.
     * As a result business logic code is executed on the scheduled thread pool. And it blocks timeouts once again.
     */
    @Test(timeout = 60_000)
    public void test04_NaiveFix_IncorrectRetryPolicyHandling() throws Exception {
        ExecutorService executorService = new ThreadPoolExecutor(
                1, 1, 1, TimeUnit.MINUTES, new SynchronousQueue<>(),
                r -> new Thread(r, "test04_NaiveFix_IncorrectRetryPolicyHandling"));
        Scheduler delegatingScheduler = Scheduler.of(executorService);
        ScheduledExecutorService scheduledExecutorService = Executors.newSingleThreadScheduledExecutor(
                r -> new Thread(r, "test04_NaiveFix_IncorrectRetryPolicyHandling-scheduled@" + r.hashCode()));
        FailsafeExecutor<?> failsafe = Failsafe.with(new RetryPolicy<>(),
                                                     Timeout.of(Duration.ofSeconds(1)).withCancel(true))
                .with((callable, delay, unit) -> {
                    if (delay == 0) {
                        return delegatingScheduler.schedule(callable, delay, unit);
                    } else {
                        // Direct execution to never fail to execute TimeoutExecutor.timeoutFuture
                        return scheduledExecutorService.schedule(callable, delay, unit);
                    }
                });
        CompletableFuture<?> firstTask = failsafe.runAsync(ctx -> {
            System.out.println("Thread: " + Thread.currentThread().getName());
            Thread.sleep(Long.MAX_VALUE);
        });
        try {
            firstTask.join();
            Assert.fail();
        } catch (CompletionException e) {
            Assert.assertTrue(e.getCause() instanceof TimeoutExceededException);
        }
    }
}

There was no simple way to fix the retry policy behaviour,
so I added a custom "async" policy that always deferred execution to
a thread pool. It could only work together with a SimpleDelegatingScheduler
introduced above in the naive fix.
Unfortunately my lack of understanding of Failsafe API prevented me from
creating an elegant solution. It fixed some, but not all the issues.
At this point I think somebody with more understanding of the internal Failsafe
piping should take over:
import com.google.common.base.MoreObjects;
import com.google.common.base.Throwables;
import net.jodah.failsafe.AbstractExecution;
import net.jodah.failsafe.ExecutionResult;
import net.jodah.failsafe.FailsafeFuture;
import net.jodah.failsafe.Policy;
import net.jodah.failsafe.PolicyExecutor;
import net.jodah.failsafe.util.concurrent.Scheduler;

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodHandles.Lookup;
import java.lang.invoke.MethodType;
import java.lang.invoke.VarHandle;
import java.util.concurrent.Callable;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import java.util.function.Supplier;

import static com.google.common.base.Preconditions.checkNotNull;

/**
 * Policy allowing move business logic execution onto a different thread pool. It takes care of threading issues
 * for several different use-cases:
 *

 *
{@code SimpleDelegatingScheduler}: In most cases
 *     it executes {@link Policy}s on the calling thread, {@code net.jodah.failsafe.TimeoutExecutor}
 *     on the {@link java.util.concurrent.ScheduledExecutorService} and main business logic on
 *     {@link ExecutorService}, and this is a good thing. Unfortunately
 *     {@code RetryPolicy} causes retries business logic to be executed on
 *     {@link java.util.concurrent.ScheduledExecutorService} which does not have enough threads for this.

 *
{@link net.jodah.failsafe.internal.util.DelegatingScheduler}: Contrary to the previous case it always
 *     executes all logic (including {@code net.jodah.failsafe.TimeoutExecutor} on an {@link ExecutorService}.
 *     Unfortunately it means that when the thread pool is full it's not possible to time out tasks already
 *     being executed, moreover these a {@link java.util.concurrent.Callable} that would cancel in-flight
 *     execution can not be scheduled, so it breaks {@code net.jodah.failsafe.TimeoutExecutor}

 *
Failsafe before version 2.3.4 had a different threading model: As all tasks (including
 *     {@code net.jodah.failsafe.TimeoutExecutor}) never executed on the calling thread. So
 *     {@code net.jodah.failsafe.TimeoutExecutor} starts timing out counter only when queue on
 *     {@link ExecutorService} is already cleaned up, not from the time when the task was scheduled.

 *

 *

 * This code you'd see in this class may frighten you, it's intentional, we tried and failed to make simpler.
 * As we execute our task asynchronously for it to be cancellable from {@code net.jodah.failsafe.TimeoutExecutor}
 * we need at least to override {@code net.jodah.failsafe.FailsafeFuture#delegate}.
 * {@link net.jodah.failsafe.Failsafe} is very protective of its internals and all the helper functions are hidden
 * e.g. {@code net.jodah.failsafe.FailsafeFuture#inject} is package private.
 * All of this means we're set up for a major surgery here and it would not be pretty.
 */
public class AsyncExecutionPolicy<R> implements Policy<R> {

    /** Follow the convention of using raw types here. */
    @SuppressWarnings({"unchecked", "rawtypes"})
    @Override
    public PolicyExecutor toExecutor(AbstractExecution execution) {
        return new AsyncExecutor(this, execution);
    }

    @Override
    public String toString() {
        return MoreObjects.toStringHelper(this)
                .toString();
    }

    static class AsyncExecutor<R> extends PolicyExecutor<AsyncExecutionPolicy<R>> {

        static final FailsafeReflectionHelper reflection = new FailsafeReflectionHelper();

        protected AsyncExecutor(AsyncExecutionPolicy<R> policy, AbstractExecution execution) {
            super(policy, execution);
        }

        /**
         * Works a bit similar to {@code net.jodah.failsafe.TimeoutExecutor}. We return a promise that is completed when
         * the async execution finishes (either successfully or not). To support cancellation we have to update
         * {@link FailsafeFuture}'s internal state and restore it back afterwards. This way when
         * {@code net.jodah.failsafe.TimeoutExecutor#supplyAsync} will do
         * {@code net.jodah.failsafe.FailsafeFuture#cancelDelegates(boolean, boolean)} it would cancel
         * business logic code and not the main thread.
         */
        @Override
        protected Supplier<CompletableFuture<ExecutionResult>> supplyAsync(
                Supplier<CompletableFuture<ExecutionResult>> supplier, Scheduler scheduler,
                FailsafeFuture<Object> future) {
            return () -> {
                CompletableFuture<ExecutionResult> promise = new CompletableFuture<>();

                try {
                    // Coordinates a result between the this and execution threads
                    synchronized (future) {
                        if (future.isDone() || execution.isFirstAttempt()) {
                            // When we're already done no need to schedule anything.
                            // On the first call net.jodah.failsafe.Functions.getPromiseAsync does async for us.
                            // TODO(tbasanov): File a ticket against Failsafe, this is confusing behaviour
                            final CompletableFuture<ExecutionResult> result = supplier.get();
                            return result;
                        }

                        Future<?> executionFuture = scheduler.schedule((Callable<?>) () -> {
                            // Execute postExecute listeners on the business logic thread, we're already
                            // running, we can as well finish without additional rescheduling
                            supplier.get().whenComplete((result, error) -> {
                                if (error != null) {
                                    promise.completeExceptionally(error);
                                } else {
                                    promise.complete(result);
                                }
                                // Don't call postExecuteAsync() as we're not a PolicyListeners-compatible
                            });
                            return null;
                        }, 0, TimeUnit.NANOSECONDS);
                        // When timeout would expire we want cancellation to affect business logic,
                        // not the current thread.
                        reflection.setFailsafeFutureDelegate(future, executionFuture);
                    }
                    return promise;
                } catch (Throwable t) {
                    // Hard scheduling failure
                    promise.completeExceptionally(t);
                    return promise;
                }
            };
        }
    }

    /** Reflection logic split into a separate class for readability. */
    static class FailsafeReflectionHelper {

        private final VarHandle failsafeFutureDelegate;
        private final MethodHandle failsafeFutureInjectTimeout;

        public FailsafeReflectionHelper() {
            try {
                Lookup failsafeFutureLookup =
                        MethodHandles.privateLookupIn(FailsafeFuture.class, MethodHandles.lookup());
                failsafeFutureDelegate = failsafeFutureLookup
                        .findVarHandle(FailsafeFuture.class, "delegate", Future.class);
                failsafeFutureInjectTimeout = failsafeFutureLookup
                        .findVirtual(FailsafeFuture.class, "injectTimeout",
                                     MethodType.methodType(void.class, Future.class));
            } catch (Exception e) {
                // This can not happen unless method signature has changed
                throw new IllegalStateException("Incompatible version of Failsafe was discovered", e);
            }
        }

        /**
         * Changes the main delegate in {@link FailsafeFuture} to the one passed, moves the previous
         * one to a list of {@code net.jodah.failsafe.FailsafeFuture#timeoutDelegates}. This allows
         * cancellation logic to cancel even the current future if necessary. Note that we don't expect
         * current future would fail as it either does not contain any business logic
         * (i.e. {@link net.jodah.failsafe.Failsafe} only) that was not yet executed. Should be equivalent to:
         *

         * synchronized(future) {
         *     Future previousDelegate = future.delegate;
         *     future.delegate = executionFuture;
         *     future.injectTimeout(previousDelegate);
         * }
         *

         */
        private void setFailsafeFutureDelegate(FailsafeFuture<?> future, Future<?> executionFuture) {
            synchronized (checkNotNull(future, "future")) {
                try {
                    // Note we can not use inject(Future) as it resets timeoutDelegates
                    Future<?> previousDelegate = (Future<?>) failsafeFutureDelegate.get(future);
                    failsafeFutureDelegate.set(future, executionFuture);
                    if (previousDelegate != null) {
                        failsafeFutureInjectTimeout.invoke(future, previousDelegate);
                    }
                } catch (Throwable t) {
                    Throwables.throwIfUnchecked(t);
                    // This can not happen unless method signature has changed
                    throw new IllegalStateException("Incompatible version of Failsafe was discovered", t);
                }
            }
        }

    }
}

Indeed, Failsafe uses the Scheduler/ThreadPool you supply via .with(Scheduler) for all async executions, including scheduled timeouts. In this case that causes a problem if the threadpool is full.
The simplest solution would be to allow policies such as Timeout to have a separately configured Scheduler if desired:
Timeout.of(Duration.ofSeconds(1)).withCancel(true).withScheduler(threadpool);

Thoughts?

That would work. And it would resolve the most immediate need today of making time outs work even when the app is slow.
Some additional thoughts on this
This does feel like a bit of a hack. Not sure if a retry/fallback policies also need a fix or not, they schedule things. This would require a bit of a hack on my side as I'm using my own policies that allow to change delay/retry/thresholds at runtime. But it's workable solution for sure. A "proper" fix may take some time as it may change how threading works within Failsafe, and it even may require to fully define Failsafe behavior in the event of resource constraints.
I think the ideal solution would be to allow to move all Failsafe logic onto a separate thread pool. My application logic is slow and heavy, so I want a big thread pool. Failsafe-logic is fast and non-blocking, it can as well run on top of a common fork join pool. This way no matter what kind of application logic I'll throw at it, it would never break retries/timeouts and all other Failsafe policies (e.g. retries.)
Ideally I'd want to execute even policy listeners on the application thread pool. This may be hard to implement given that all listeners are currently done in a fully sync manner. To make things worse this desire clashes with the fact that I want to be able to execute policy listener even if my main thread pool is busy. Example of a listener would be adding debug information to the response when something is starting to fail (before ultimately sending it back via a fallback policy) even when main thread pool got fully stuck in a busy wait and ignoring cancellations.
One more related note on thread pools is that ideally Failsafe should create all callables that would execute application logic on threads from the application logic thread pool (even if the actual scheduling may not happen later on). This makes it much easier to make tracing/context passing work, as I don't have to think about Failsafe internal implementation at all.
I think the cheapest way with full backwards compatibility is to always schedule application logic via schedule(callable, 0) and schedule all Failsafe logic via schedule(callable, !=0). It's very close to what Failsafe already does with a few exceptions.
Going further may be even changing Scheduler interface to have two or three methods: Future scheduleApplicationLogic(callable), ScheduledFuture scheduleFailsafeCode(callable, delay), Future scheduleFailsafeCode(callable). It is convenient to have a separate method for 0-delay scheduling method as then I can return Future instead. Non-scheduled future is much easier to create with if I already have complicated custom thread pools that can not support scheduling.

Sorry about such an unstructured response. I do not have any definitive answers and even some of my requirements are mutually exclusive. But I hope that some of these ideas would give you some insight into my difficulties.

This is not a contribution.

As with issue 263, I think we should limit our expectations of what the Timeout policy can achieve.
In this issue and in #260, the problem boils down to contention between application code and Failsafe internals for a limited number of available threads. But threads are potentially scarce system resources, and we don't expect Failsafe to handle the depletion of other system resources, like heap memory, gracefully. Using separate thread pools gives the illusion of having independent sandboxes, but ultimately there are limits imposed by the JVM, by other processes on the machine running the JVM, and potentially by other machines running on the same virtualized hardware. This issue and #260 demonstrate how things can break down under thread scarcity, but they aren't direct indictments of Timeout.
That said, I think it would be good to explore @timothybasanov's idea of moving some Failsafe internals, particularly the Timeout internals, to the common FJP. Failing that, I think @jhalterman's idea above, of allowing Timeouts to optionally be configured with a different thread pool, is reasonable.

I think the cheapest way with full backwards compatibility is to always schedule application logic via schedule(callable, 0) and schedule all Failsafe logic via schedule(callable, !=0).

I'm not sure about this. There's a performance penalty associated with a non-zero delay. More importantly, it could subtly change timing that users were (perhaps unreasonably) relying on. Better to hash the larger issue out carefully, waiting for a major version change, and not risk a lot of complaints from users whose code suddenly stops working.

The Timeout aspect of this issue was resolved in e41381b11912d8ec09e49bc3a067f50b5285faf3, where Timeouts now use the internal Scheduler (backed by the common ForkJoinPool, when possible).


fix: compile error

修复一个编译错误

 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.houjianxin.rupert seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@jianxinhou can you sign the CLA license?

改好了，之前的提交邮箱和登录邮箱不一致，所以没签成功。


Update Composer dependencies (2024-07-05-00-18)

Visual regression test passed!
View the visual regression test report


x-ms-enum - KeyNotFoundException: The given key was not present in the dictionary.

I am attempting to generate a C# client library using the following swagger:
swagger: '2.0'
info:
  title: API
  description: API for exposing endpoints.
  termsOfService: 'http://tempuri.org/terms'
  contact:
    name: Bleh
    email<EMAIL_ADDRESS>  version: 1.0.0
paths:
  '/api/v1/{authId}/documents':
    get:
      tags:
        - Documents
      summary: Retrieves user's uploaded documents meta-data.
      operationId: Documents_GetAll
      produces:
        - text/plain
        - application/json
        - text/json
      parameters:
        - in: path
          name: authId
          description: User's unique auth identifier.
          required: true
          type: string
      responses:
        '200':
          description: Success
          schema:
            type: array
            items:
              $ref: '#/definitions/DocumentMetaData'
        '401':
          description: Unauthorized
        '403':
          description: Forbidden
      security:
        - OAuth2:
            - ''
    post:
      tags:
        - Documents
      summary: Uploads a new document to user's storage.
      operationId: Documents_Upload
      consumes:
        - multipart/form-data
      produces:
        - text/plain
        - application/json
        - text/json
      parameters:
        - in: path
          name: authId
          description: User's unique auth identifier.
          required: true
          type: string
      responses:
        '201':
          description: Success
          schema:
            type: string
        '401':
          description: Unauthorized
        '403':
          description: Forbidden
        '415':
          description: Client Error
          schema:
            $ref: '#/definitions/ProblemDetails'
      security:
        - OAuth2:
            - ''
  '/api/v1/{authId}/documents/{fileName}':
    get:
      tags:
        - Documents
      summary: Retrieves a URI to the document.
      operationId: Documents_GetUri
      produces:
        - text/plain
        - application/json
        - text/json
      parameters:
        - in: path
          name: authId
          description: User's unique auth identifier.
          required: true
          type: string
        - in: path
          name: fileName
          description: Name of the file to retrieve.
          required: true
          type: string
      responses:
        '200':
          description: Success
          schema:
            format: uri
            type: string
        '401':
          description: Unauthorized
        '403':
          description: Forbidden
        '404':
          description: Not Found
          schema:
            $ref: '#/definitions/ProblemDetails'
      security:
        - OAuth2:
            - ''
  '/api/v1/{authId}/documents/{id}':
    put:
      tags:
        - Documents
      summary: Updates an existing document's meta-data.
      operationId: Documents_Update
      consumes:
        - application/json
        - text/json
        - application/*+json
      produces:
        - text/plain
        - application/json
        - text/json
      parameters:
        - in: path
          name: authId
          description: User's unique auth identifier.
          required: true
          type: string
        - in: path
          name: id
          description: Unique document identifier.
          required: true
          type: string
        - in: body
          name: body
          description: Update data for the document's meta-data.
          schema:
            $ref: '#/definitions/DocumentMetaDataUpdate'
      responses:
        '204':
          description: Success
        '400':
          description: Bad Request
          schema:
            $ref: '#/definitions/ProblemDetails'
        '401':
          description: Unauthorized
        '403':
          description: Forbidden
        '404':
          description: Not Found
          schema:
            $ref: '#/definitions/ProblemDetails'
      security:
        - OAuth2:
            - ''
    delete:
      tags:
        - Documents
      summary: Deletes a document and associated meta-data.
      operationId: Documents_Delete
      produces:
        - text/plain
        - application/json
        - text/json
      parameters:
        - in: path
          name: authId
          description: User's unique auth identifier.
          required: true
          type: string
        - in: path
          name: id
          description: Unique document identifier.
          required: true
          type: string
      responses:
        '204':
          description: Success
        '401':
          description: Unauthorized
        '403':
          description: Forbidden
        '404':
          description: Not Found
          schema:
            $ref: '#/definitions/ProblemDetails'
      security:
        - OAuth2:
            - ''
definitions:
  DocumentType:
    description: Document type.
    enum:
      - SeamanBook
      - Passport
    type: string
    x-ms-enum:
      name: DocumentType
      modelAsString: true
  DocumentMetaData:
    description: Document meta data model.
    type: object
    properties:
      id:
        description: Document meta data unique identifier.
        type: string
      documentType:
        description: Type of document.
        allOf:
          - $ref: '#/definitions/DocumentType'
      identifier:
        description: Document identifier (not unique).
        type: string
      startDate:
        format: date-time
        description: Date the document started.
        type: string
      endDate:
        format: date-time
        description: Date the document ended.
        type: string
      placeOfIssue:
        description: Place the document was issued.
        type: string
      notes:
        description: Notes/description of the document.
        type: string
      filePath:
        description: Path of where the document is stored.
        type: string
      uploaded:
        format: date-time
        description: Date and time when the document was uploaded.
        type: string
      modified:
        format: date-time
        description: Date and time the meta data was last modified.
        type: string
  DocumentMetaDataCreate:
    description: Document meta data create model.
    type: object
    properties:
      documentType:
        description: Type of document.
        allOf:
          - $ref: '#/definitions/DocumentType'
      identifier:
        description: Document identifier (not unique).
        type: string
      startDate:
        format: date-time
        description: Date the document started.
        type: string
      endDate:
        format: date-time
        description: Date the document ended.
        type: string
      placeOfIssue:
        description: Place the document was issued.
        type: string
      notes:
        description: Notes/description of the document.
        type: string
  ProblemDetails:
    type: object
    properties:
      type:
        type: string
      title:
        type: string
      status:
        format: int32
        type: integer
      detail:
        type: string
      instance:
        type: string
    additionalProperties:
      type: object
  DocumentMetaDataUpdate:
    description: Document meta-data update model.
    type: object
    properties:
      id:
        description: Document meta data unique identifier.
        type: string
      documentType:
        description: Type of document.
        allOf:
          - $ref: '#/definitions/DocumentType'
      identifier:
        description: Document identifier (not unique).
        type: string
      startDate:
        format: date-time
        description: Date the document started.
        type: string
      endDate:
        format: date-time
        description: Date the document ended.
        type: string
      placeOfIssue:
        description: Place the document was issued.
        type: string
      notes:
        description: Notes/description of the document.
        type: string
securityDefinitions:
  OAuth2:
    type: oauth2
    flow: application
    tokenUrl: 'http://localhost:5555/connect/token'
    scopes:
      documents: ''
    description: 'Login with your bearer authentication token, e.g. Bearer <auth-token>'

and when I do I get the following error:

I've tracked the problem down to the inclusion of the DocumentType enum in the following models:

DocumentMetaData
DocumentMetaDataCreate
DocumentMetaDataUpdate

But what I can see from your documentation (https://github.com/Azure/autorest/blob/master/docs/extensions/readme.md#x-ms-enum) I appear to be declaring the enum correctly.

I'm encountering the same issue generating a C# schema with an enums.  Are there any updates on this?


Add support for generic player chat commands (trigger words)

Add generic player chat commands (trigger words)
Add a cache (MostRecentEvents) that is updated every kill or team kill
Refactored scorebot/scoreboard stuff a little bit to use their types/lookups elsewhere
Adds a discord_invite_url option to RconServerSettingsType
Updates the webhook user configs to return a sorted list of admin ping words to guarantee the order when running tests
Adds SafeStringFormat a subclass of dict that will accept any formatted string and replace missing keys with the key itself to avoid exceptions when using "".format_map()"

This supports two types of information, info we can get from anywhere in the RCON without any extra details (server name, etc.) and info that is only available depending on the context. This is represented by two types (MessageVariable and MessageVariableContext).
It does pass in the steam_id_64 when used in rcon.hooks.trigger_words since the chatting players steam ID is always available and allows us to look up VIP status, etc.
Users can add as many commands/command formats as they want, but they can only add {variable} style variables if they're either in the MessageVariable or MessageVariableContext enums to avoid typos, etc.
This does require some more work to support the rest of the scoreboard types, and if this is an acceptable way to do this, we could use this across the board in other places in RCON (automods, etc.) to allow people more options when automatically messaging players.
We can also use this to add end of round stuff for #392

Seems quite good for me, but I'd prefer FlorianSW to approve this one.

Okay I:

Added the player names back into the cache so it's easier to use
Expanded/updated the tests
Renamed everything so that these are command words instead of trigger words, it's more descriptive and it won't conflict with names if we add a generic BM style trigger system later
Forced commands to be limited to ! and @ prefixes only
Set ? as the prefix to trigger the description of a command
Set the recent player actions (kills, etc.) cache to be reset on match start
Updated the recent player actions cache TTL to 2.5 hours since that's the longest possible HLL match currently
Forced the player cache to update the redis cache when it's set so it's available in other Python interpreter instances
Added the permissions for the endpoints

Looks good :) Feel free to merge after the conflicts are resolved 🤗


Add CI check for arm64

CICD added arm64 builds, so this adds a check to verify those image builds
Signed-off-by: Dale Haiducek<EMAIL_ADDRESS>

/hold
There are quite a few failures here. Let me check with CICD before we deploy this and start getting false positives:
****
PROW STATUS REPORT:
***
ERROR: Prow job failure: cert-policy-controller main
   Link: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/branch-ci-stolostron-cert-policy-controller-main-images-arm64/1617906584602546176
ERROR: Prow job failure: cert-policy-controller 2.6
   Link: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/branch-ci-stolostron-cert-policy-controller-release-2.6-images-arm64/1617917255876612096
ERROR: Prow job failure: cert-policy-controller 2.7
   Link: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/branch-ci-stolostron-cert-policy-controller-release-2.7-images-arm64/1617918580291014656
ERROR: Prow job failure: governance-policy-framework main
   Link: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/branch-ci-stolostron-governance-policy-framework-main-images-arm64/1617618845793521665
ERROR: Prow job failure: governance-policy-propagator 2.4
   Link: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/branch-ci-stolostron-governance-policy-propagator-release-2.4-images-arm64/1587540436036096000
ERROR: Prow job failure: iam-policy-controller 2.7
   Link: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/branch-ci-stolostron-iam-policy-controller-release-2.7-images-arm64/1617916603859472384
***

The images are for building arm64 upstream. Let's continue to hold this PR, and I'll create an issue to address these along with merging the PR in the future.

Closing for now since I'm not aware of this being all that high of a priority.


Elastalert HA

Hi,
I read already here that it is not a good idea to run elastalert in different servers at same time. We are looking for different possibilities to make it high available. But I was wondering if there is any autorecovery configuration already in place.
We have install it as a windows service and with the autorecovery options but we are thinking how to handle a second instance that can act as a backup in case the autorecovery is not enough.
Thanks and kind regards,
Ruth

This is for sure something I'd also like to know. Relying on a single instance of ElastAlert is not really good enough in my opinion.

Don't suppose anyone has gotten any good responses on this yet?

So one idea might be... have the service run on N number of elasticsearch nodes but always check for the elected "master" before committing to an action.
This way if a esearch node falls over, the newly elected master could also resume alerting responsibilities.

@Qmando Any suggestions on this?

If you run with a service discovery mechanism this can be trivially done.
Likewise if you run on an orchestration service..

ElastAlert saves all of it's state to Elasticsearch so it can be stopped, moved, restarted, etc without losing data. There are also some mechanisms to avoid catastrophic failure if some code raises an exception, Elasticsearch goes down, or similar errors, but obviously it's not perfect.
Service monitoring, autorestarting, failover, and testing changes before deploying them is not something Elastalert is responsible for at this time.
ElastAlert is still very lightweight and adding it's own mechanism of distributed discovery and availability is a large task, though potentially it will support these in the future.

ElastAlert saves all of it's state to Elasticsearch so it can be stopped, moved, restarted, etc without losing data.
I think this depends on the rule being used.  Some of them, like frequency, I think, keep counts in memory.  This data is lost if ElastAlert is restarted.  So, I think the solution that @mlosapio describes would take this into account.


Add ‘cyclosm.org’

Please add https://www.cyclosm.org.
Infos:

https://2019.stateofthemap.org/sessions/SBDEU8/
https://www.youtube.com/watch?v=wwUWEb1TJMs

Thanks!

This is due to be supported in the next release.


Perforce 'Mark for Add' causing import error

Hello,
I get an error cropping up due to Perforce insisting on 'Mark for Add' being okayed on new files. I get a pop up window on the Waapi saying 'some files could not be imported into Wwise. The associated render queue projects have been re-created'.
The files DO in fact get imported but the error is a bit misleading. I'm not sure if there is anyway around this?
Thanks

Same thing happens to me with SVN. The problem happens because WWISE asks me to confirm if I want new files to be added to SVN repo.
If I manage to click YES quickly for every sound while rendering is active everything goes smoothly, like in gif below.

But, if I fail to click confirmation dialog on time some sounds remain in BouncedSounds folder even though I uncheked "Copy Files to Wwise Originals" and they remain in my Render Queue inside REAPER.

This is very annoying and it would be extremely eficient to override this dialog box inside WAAPI Transfer.
I export a large number of files from REAPER everyday and I would like to have this solved, if possible. A simple YES TO ALL would be nice.

Hi  @undertheradar84 and @nikolalkc  - please try https://github.com/karltechno/Reaper-Waapi-Transfer/releases/tag/v0.1.8-beta and let me know if this fixes the issue, thanks.

@karltechno  Thank you for responding so quickly. This fix actually helps. Error message doesn't pop up anymore, but, I still have to click YES in wwise for every that is exported from REAPER. Is there a way to override this dialog so WAAPI Transfer automatically marks all new files for Add in source control?

@nikolalkc From a cursory glance I can't see anything in the schema allowing me to do that: https://www.audiokinetic.com/library/edge/?source=SDK&id=ak__wwise__core__audio__import.html - additionally it seems as though source control operations aren't available to WAAPI currently: https://www.audiokinetic.com/qa/4347/how-to-create-a-new-workunit-using-waapi

Oh well, we'll just have to wait for those options to be implemented. Thanks again.


Bump raven client to latest version

This package is deprecated and a better alternative has been created, please use Cabin: https://cabinjs.com


Add find_in_batches method

Hello @jnunemaker .
I sometimes want to use Plucky#find_each as like ActiveRecord's find_in_batches and I substitute find_each(opts).each_slice(batch_size) for that.
But I thought that it's useful for also other mongomapper users to add the find_in_batches method to plucky queries.
I would appreciate it if you would review this, thank you.

I'm not involved with mongomapper or plucky anymore. I believe @cheald is still maintaining them.

@jnunemaker
I'm very sorry to disturb, and appreciate you mentioning the maintainer.

Seems this repo is no longer maintained...


Missing wolf texture found in taiga for 1.20.1

I've seen one other post talking about this issue and it was a few months old and has not been resolved.

I have the same issue

I looked through the files, the pale wolf textures are missing. Not sure what to do about that...


Keep lists etc split across multiple lines

Black's wrapping of lists to fit a single line causes diffs to become bigger,
and often makes the code harder to read.
When removing the 3rd line from the list used in the for loop, it will become
short enough to fit a single line and black re-formats it:
Orig:
normid = p.basename + "::TestClass::()::test_method"
for id in [
    p.basename,
    p.basename + "::TestClass",
    p.basename + "::TestClass::()",
    normid,
]:

New:
normid = p.basename + "::TestClass::()::test_method"
for id in [
    p.basename,
    p.basename + "::TestClass",
    normid,
]:

Black:
normid = p.basename + "::TestClass::test_method"
for id in [p.basename, p.basename + "::TestClass", normid]:

I think black should instead keep the original list style (which matches what
black would do with more entries), and only remove the single line.
This would not need an option, but could be respected in general: if a list (or
dictionary etc) is wrapped already like black would wrap it with more entries
than would fit on a single line it should keep it like this.
The list itself should still get re-formatted, but should just be considered to not fit a single line.

For me this is more about readability as well as consistency.
One case I find it especially taxing to read mixed formatting is when using click decorators. This can require the eyes of a reader to bounce back and forth significantly, making the code more difficult to read.
Another case is comprehensions. I find it is always easier for programmers (especially those new/unfamiliar with Python) to read a comprehensions written like:
[
    expression
    for item in iterable
    if condition
]

I try to write my code so it's as easy as possible for someone to contribute. This is one of the lowest hanging fruits toward that goal. Having this syntax formatted based on line length also creates inconsistency that can confuse people new to Python. Why is it written this way here, but not there?

I think need add of the inline parametrize.

considering this is on the very top of the documentation:

Black makes code review faster by producing the smallest diffs possible.

i agree.
it also hurts readability, like in this example of a logging configuration:
-        'py.warnings': {
-            'handlers': ['null'],
-            'level': 'WARNING',
-            'propagate': False,
-        },
+        'py.warnings': {'handlers': ['null'], 'level': 'WARNING', 'propagate': False},

It seems to me that this would break a symmetry. Code formatted with black should be unchanged if we change the line length and then revert the change (black -l 40 then black again).

It seems to me that this would break a symmetry. Code formatted with black should be unchanged if we change the line length and then revert the change (black -l 40 then black again).

Yes, as @jebob says, the proposal from this issue would break the larger principle that Black-formatted code looks the same no matter what it originally looked like.

Perhaps I'm missing something... but if this isn't controlled strictly by line length as proposed, it shouldn't be affected by roundtripping changing the line length as described.

Another alternative is to always split collection displays into multiple lines, but that seems undesirable too (we'd split code like x = [1, 2] into four lines)

That is what has been suggested by the OP, myself, and others in this issue as being desirable. Black tries for uniformity, specifically for horizontal whitespace. While I didn't post code, my description of click decorators can easily exhibit a lack of uniformity that is distracting and harder to read. I don't see why changing your given example into 4 lines is undesirable; it would then be consistent with other pieces of code like it within a codebase that gets reformatted onto multiple lines. And arguments given why black splits pieces of code like it still apply (e.g. smaller diffs).
As it is now, I can only possibly use black as a pre-formatter followed by my manually re-formatting the black-formatted code. If it's preferable for the splitting behavior to be controlled by an option rather than hard-coded one way or another, I'm definitely fine with that.

The way clang-format handles literals of this type is that all elements are kept on a single line iff there's a trailing comma, and if there's no trailing comma then it'll try and pack all on a single line if it can, otherwise do splitting. That has felt like a good compromise to me.

all elements are kept on a single line iff there's a trailing comma

Wouldn't it make more sense to do so iff there's no trailing comma?
Otherwise mutliline lists wouldn't have it, leading to unnecessary bigger diffs.

Shoot, I inverted the logic halfway through. Yes, what you said is what clang-format does. Sorry for the confusion.

We'll keep the current behavior for now.

This issue also bothers me. When defining many lists (or in our case, Django models), it really hurts readability and diffs that some are multi-line and some are single-line.
My thought would be to add a --multiline flag to black that would always split lists, dicts, function calls etc. over multiple lines rather than trying to cram some on a single line and some multi-line. Of course, I can see how this goes against black's philosophy of not providing any configuration options.
Would the project be willing to consider a PR that adds this functionality?

We're hoping the approach in #826 would fix this pain point.


Convert to module (ESM).

BREAKING: Convert to module (ESM).
BREAKING: Require Node.js >=14.
Update dependencies.
Lint module.

Codecov Report

Merging #8 (fda22ea) into main (807dc33) will increase coverage by 0.52%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main       #8      +/-   ##
==========================================
+ Coverage   87.83%   88.35%   +0.52%
==========================================
  Files           5        4       -1
  Lines         189      498     +309
==========================================
+ Hits          166      440     +274
- Misses         23       58      +35

Impacted Files
Coverage Δ

lib/index.js
100.00% <100.00%> (ø)

test/X25519KeyAgreementKey2020.spec.js

lib/crypto.js
94.64% <0.00%> (+6.40%)
:arrow_up:

lib/X25519KeyAgreementKey2020.js
88.30% <0.00%> (+7.87%)
:arrow_up:

lib/crypto-nacl.js
68.42% <0.00%> (+68.42%)
:arrow_up:

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 807dc33...fda22ea. Read the comment docs.


Restructure test locations

tests-cuda-kernels will be a new directory in the future

I had edited the CI for just macOS and not Linux and Windows, causing the tests to fail. All the tests pass now.


pdns: 4.6.3 -> 4.7.2

Description of changes
Changelogs: https://doc.powerdns.com/authoritative/changelog/4.7.html
Upgrade Notes: https://doc.powerdns.com/authoritative/upgrading.html#to-4-7-0-or-master

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

Does the module handle the sql schema upgrades, mentioned in the upgrade notes? If not, we should probably add this to the release notes.


fix bug for https://github.com/bytefish/PgBulkInsert/issues/48

https://github.com/bytefish/PgBulkInsert/issues/48

I have implemented it the same way as in the PostgreSQLCopyHelper library.

@tangyibo Thanks for raising the issue and bringing it to my attention. Also thanks for the effort you put into the Pull Request! 👍