Dark mode elevation overlay color is only applied to Material of type canvas, when surface and background colors are equal

Description
In dark mode, when using themes that specify applyElevationOverlayColor: true with themes that specify slightly different background and surface colors, the Material dark mode overlay color only gets applied correctly to Material of type card, it is not applied to Material of type canvas.
If we are using the same themed color for background and surface in a dark theme, then elevation overlay color is applied to both Material of type canvas and of type card. This behavior is inconsistent and not expected.
Expected behavior would be to get the elevation overlay color also on Material of of type canvas, even if its themed color differs slighlt from surface color.
This issue applies to
All Flutter channels and all platforms.
Steps to Reproduce
In dark mode, when using theme's that specify applyElevationOverlayColor: true themes with default background and surface colors get elevation overlay color applied correctly, as shown here:
OK - Default or Equal background & surface colors => Elevation overlay is OK

OK - Default background and surface - Example code
import 'package:flutter/material.dart';

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

// Light theme mode colors.
const Color kLightPrimary = Color(0xFF0A496A);
const Color kLightPrimaryVariant = Color(0xFF2A9D8F);
const Color kLightSecondary = Color(0xFFF86541);
const Color kLightSecondaryVariant = Color(0xFFF07E24);

// Dark theme mode colors.
const Color kDarkPrimary = Color(0xFF62AEDC);
const Color kDarkPrimaryVariant = Color(0xFF50A399);
const Color kDarkSecondary = Color(0xFFF06E4B);
const Color kDarkSecondaryVariant = Color(0xFFD57534);

class MyApp extends StatefulWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  State<MyApp> createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  ThemeMode themeMode = ThemeMode.dark;

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      title: 'Flutter Demo',
      theme: ThemeData.from(
        colorScheme: const ColorScheme.light(
          primary: kLightPrimary,
          primaryVariant: kLightPrimaryVariant,
          secondary: kLightSecondary,
          secondaryVariant: kLightSecondaryVariant,
        ),
      ).copyWith(
        scaffoldBackgroundColor:
            Color.alphaBlend(kLightPrimary.withAlpha(0x05), Colors.white),
      ),
      darkTheme: ThemeData.from(
          colorScheme: const ColorScheme.dark(
        primary: kDarkPrimary,
        primaryVariant: kDarkPrimaryVariant,
        secondary: kDarkSecondary,
        secondaryVariant: kDarkSecondaryVariant,
      )).copyWith(
        scaffoldBackgroundColor: Color.alphaBlend(
            kDarkPrimary.withAlpha(0x05), const Color(0xff121212)),
      ),
      themeMode: themeMode,
      home: MyHomePage(
        title: 'Flutter Demo Home Page',
        themeMode: themeMode,
        onThemeModeChanged: (ThemeMode mode) {
          setState(() {
            themeMode = mode;
          });
        },
      ),
    );
  }
}

class MyHomePage extends StatelessWidget {
  const MyHomePage({
    Key? key,
    required this.title,
    required this.themeMode,
    required this.onThemeModeChanged,
  }) : super(key: key);

  final String title;
  final ThemeMode themeMode;
  final ValueChanged<ThemeMode> onThemeModeChanged;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(title),
      ),
      body: ListView(
        padding: const EdgeInsets.all(32),
        children: <Widget>[
          const Text('Toggle theme'),
          ThemeModeSwitch(
            themeMode: themeMode,
            onChanged: onThemeModeChanged,
          ),
          const Divider(),
          const ShowThemeColors(),
          const Divider(),
          const Material(
            type: MaterialType.canvas,
            elevation: 0,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type canvas, elevation 0'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            type: MaterialType.canvas,
            elevation: 1,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type canvas, elevation 1'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            type: MaterialType.canvas,
            elevation: 4,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type canvas, elevation 4'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            type: MaterialType.canvas,
            elevation: 8,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type canvas, elevation 8'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Divider(),
          const Material(
            elevation: 0,
            type: MaterialType.card,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type card, elevation 0'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            elevation: 1,
            type: MaterialType.card,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type card, elevation 1'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            elevation: 4,
            type: MaterialType.card,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type card, elevation 4'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            elevation: 8,
            type: MaterialType.card,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type card, elevation 8'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Divider(),
          const Card(
            elevation: 0,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Card widget, elevation 0'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Card(
            elevation: 1,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Card widget, elevation 1'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Card(
            elevation: 4,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Card widget, elevation 4'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Card(
            elevation: 8,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Card widget, elevation 8'),
              ),
            ),
          ),
          const Divider(),
        ],
      ),
    );
  }
}

/// Widget used to toggle the theme style of the application.
@immutable
class ThemeModeSwitch extends StatelessWidget {
  const ThemeModeSwitch({
    Key? key,
    required this.themeMode,
    required this.onChanged,
  }) : super(key: key);
  final ThemeMode themeMode;
  final ValueChanged<ThemeMode> onChanged;

  @override
  Widget build(BuildContext context) {
    final List<bool> isSelected = <bool>[
      themeMode == ThemeMode.light,
      themeMode == ThemeMode.system,
      themeMode == ThemeMode.dark,
    ];
    return ToggleButtons(
      isSelected: isSelected,
      onPressed: (int newIndex) {
        if (newIndex == 0) {
          onChanged(ThemeMode.light);
        } else if (newIndex == 1) {
          onChanged(ThemeMode.system);
        } else {
          onChanged(ThemeMode.dark);
        }
      },
      children: const <Widget>[
        Icon(Icons.wb_sunny),
        Icon(Icons.phone_iphone),
        Icon(Icons.bedtime),
      ],
    );
  }
}

// Draw a number of boxes showing the colors of key theme color properties
// in the ColorScheme of the inherited ThemeData and some of its key color
// properties.
// This widget is just used so we can visually see the active theme colors
// in the examples and their used FlexColorScheme based themes.
class ShowThemeColors extends StatelessWidget {
  const ShowThemeColors({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    final ThemeData theme = Theme.of(context);
    final ColorScheme colorScheme = theme.colorScheme;
    final Color appBarColor =
        theme.appBarTheme.backgroundColor ?? theme.primaryColor;

    // A Wrap widget is just the right handy widget for this type of
    // widget to make it responsive.
    return Wrap(
      spacing: 4,
      runSpacing: 4,
      crossAxisAlignment: WrapCrossAlignment.center,
      children: <Widget>[
        ThemeCard(
          label: 'Primary',
          color: colorScheme.primary,
          textColor: colorScheme.onPrimary,
        ),
        ThemeCard(
          label: 'Primary\nColor',
          color: theme.primaryColor,
          textColor: theme.primaryTextTheme.subtitle1!.color ?? Colors.white,
        ),
        ThemeCard(
          label: 'Primary\nColorDark',
          color: theme.primaryColorDark,
          textColor:
              ThemeData.estimateBrightnessForColor(theme.primaryColorDark) ==
                      Brightness.dark
                  ? Colors.white
                  : Colors.black,
        ),
        ThemeCard(
          label: 'Primary\nColorLight',
          color: theme.primaryColorLight,
          textColor:
              ThemeData.estimateBrightnessForColor(theme.primaryColorLight) ==
                      Brightness.dark
                  ? Colors.white
                  : Colors.black,
        ),
        ThemeCard(
          label: 'Secondary\nHeader',
          color: theme.secondaryHeaderColor,
          textColor: ThemeData.estimateBrightnessForColor(
                      theme.secondaryHeaderColor) ==
                  Brightness.dark
              ? Colors.white
              : Colors.black,
        ),
        ThemeCard(
          label: 'Primary\nVariant',
          color: colorScheme.primaryVariant,
          textColor: ThemeData.estimateBrightnessForColor(
                      colorScheme.primaryVariant) ==
                  Brightness.dark
              ? Colors.white
              : Colors.black,
        ),
        ThemeCard(
          label: 'Secondary',
          color: colorScheme.secondary,
          textColor: colorScheme.onSecondary,
        ),
        ThemeCard(
          label: 'Toggleable\nActive',
          color: theme.toggleableActiveColor,
          textColor: ThemeData.estimateBrightnessForColor(
                      theme.toggleableActiveColor) ==
                  Brightness.dark
              ? Colors.white
              : Colors.black,
        ),
        ThemeCard(
          label: 'Secondary\nVariant',
          color: colorScheme.secondaryVariant,
          textColor: ThemeData.estimateBrightnessForColor(
                      colorScheme.secondaryVariant) ==
                  Brightness.dark
              ? Colors.white
              : Colors.black,
        ),
        ThemeCard(
          label: 'AppBar',
          color: appBarColor,
          textColor: ThemeData.estimateBrightnessForColor(appBarColor) ==
                  Brightness.dark
              ? Colors.white
              : Colors.black,
        ),
        ThemeCard(
          label: 'Bottom\nAppBar',
          color: theme.bottomAppBarColor,
          textColor:
              ThemeData.estimateBrightnessForColor(theme.bottomAppBarColor) ==
                      Brightness.dark
                  ? Colors.white
                  : Colors.black,
        ),
        ThemeCard(
          label: 'Divider',
          color: theme.dividerColor,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Background',
          color: colorScheme.background,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Canvas',
          color: theme.canvasColor,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Surface',
          color: colorScheme.surface,
          textColor: colorScheme.onSurface,
        ),
        ThemeCard(
          label: 'Card',
          color: theme.cardColor,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Dialog',
          color: theme.dialogBackgroundColor,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Scaffold\nbackground',
          color: theme.scaffoldBackgroundColor,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Error',
          color: colorScheme.error,
          textColor: colorScheme.onError,
        ),
      ],
    );
  }
}

// This is just simple SizedBox with a Card with a passed in label, background
// and text label color. Used to show the colors of a theme color property.
class ThemeCard extends StatelessWidget {
  const ThemeCard({
    Key? key,
    required this.label,
    required this.color,
    required this.textColor,
  }) : super(key: key);

  final String label;
  final Color color;
  final Color textColor;

  @override
  Widget build(BuildContext context) {
    return SizedBox(
      height: 50,
      width: 85,
      child: Card(
        margin: EdgeInsets.zero,
        shape: RoundedRectangleBorder(
          borderRadius: BorderRadius.circular(4),
          side: BorderSide(
            color: Theme.of(context).dividerColor,
          ),
        ),
        elevation: 0,
        color: color,
        child: Center(
          child: Text(
            label,
            style: TextStyle(color: textColor, fontSize: 12),
            textAlign: TextAlign.center,
          ),
        ),
      ),
    );
  }
}

Issue: Using surface and background colors that are not equal
If we define colors for background and surface in dark theme mode that are different from each other, we no longer get any elevation color overlay on Material using the background color, that Material of type canvas uses for its color. We still do get it on Material using the surface colored material, which Material of type card uses.
This is inconsistent with the default built in background colors behavior and also not consistent with expected behavior when using Material type canvas with elevation > 0.
Typically one gets into to this situation when using background and surface colors that for example blend in a bit of primary color into the surfaces, but do so at different strength for background and surface, for more a nuanced primary color branded designed.
Fail example
In this example we create such a theme to demonstrate the issue. With this example we can see that we no longer get any elevation color applied to Material of type canvas.

FAIL - No background overlay elevation color - Example code
import 'package:flutter/material.dart';

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

// Light theme mode colors.
const Color kLightPrimary = Color(0xFF0A496A);
const Color kLightPrimaryVariant = Color(0xFF2A9D8F);
const Color kLightSecondary = Color(0xFFF86541);
const Color kLightSecondaryVariant = Color(0xFFF07E24);

// Dark theme mode colors.
const Color kDarkPrimary = Color(0xFF62AEDC);
const Color kDarkPrimaryVariant = Color(0xFF50A399);
const Color kDarkSecondary = Color(0xFFF06E4B);
const Color kDarkSecondaryVariant = Color(0xFFD57534);

class MyApp extends StatefulWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  State<MyApp> createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  ThemeMode themeMode = ThemeMode.dark;

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      title: 'Flutter Demo',
      theme: ThemeData.from(
        colorScheme: ColorScheme.light(
          primary: kLightPrimary,
          primaryVariant: kLightPrimaryVariant,
          secondary: kLightSecondary,
          secondaryVariant: kLightSecondaryVariant,
          background:
              Color.alphaBlend(kLightPrimary.withAlpha(0x10), Colors.white),
          surface:
              Color.alphaBlend(kLightPrimary.withAlpha(0x20), Colors.white),
        ),
      ).copyWith(
        scaffoldBackgroundColor:
            Color.alphaBlend(kLightPrimary.withAlpha(0x05), Colors.white),
      ),
      darkTheme: ThemeData.from(
          colorScheme: ColorScheme.dark(
        primary: kDarkPrimary,
        primaryVariant: kDarkPrimaryVariant,
        secondary: kDarkSecondary,
        secondaryVariant: kDarkSecondaryVariant,
        background: Color.alphaBlend(
            kDarkPrimary.withAlpha(0x25), const Color(0xff121212)),
        surface: Color.alphaBlend(
            kDarkPrimary.withAlpha(0x40), const Color(0xff121212)),
      )).copyWith(
        scaffoldBackgroundColor: Color.alphaBlend(
            kDarkPrimary.withAlpha(0x05), const Color(0xff121212)),
      ),
      themeMode: themeMode,
      home: MyHomePage(
        title: 'Flutter Demo Home Page',
        themeMode: themeMode,
        onThemeModeChanged: (ThemeMode mode) {
          setState(() {
            themeMode = mode;
          });
        },
      ),
    );
  }
}

class MyHomePage extends StatelessWidget {
  const MyHomePage({
    Key? key,
    required this.title,
    required this.themeMode,
    required this.onThemeModeChanged,
  }) : super(key: key);

  final String title;
  final ThemeMode themeMode;
  final ValueChanged<ThemeMode> onThemeModeChanged;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(title),
      ),
      body: ListView(
        padding: const EdgeInsets.all(32),
        children: <Widget>[
          const Text('Toggle theme'),
          ThemeModeSwitch(
            themeMode: themeMode,
            onChanged: onThemeModeChanged,
          ),
          const Divider(),
          const ShowThemeColors(),
          const Divider(),
          const Material(
            type: MaterialType.canvas,
            elevation: 0,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type canvas, elevation 0'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            type: MaterialType.canvas,
            elevation: 1,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type canvas, elevation 1'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            type: MaterialType.canvas,
            elevation: 4,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type canvas, elevation 4'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            type: MaterialType.canvas,
            elevation: 8,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type canvas, elevation 8'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Divider(),
          const Material(
            elevation: 0,
            type: MaterialType.card,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type card, elevation 0'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            elevation: 1,
            type: MaterialType.card,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type card, elevation 1'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            elevation: 4,
            type: MaterialType.card,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type card, elevation 4'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Material(
            elevation: 8,
            type: MaterialType.card,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Material type card, elevation 8'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Divider(),
          const Card(
            elevation: 0,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Card widget, elevation 0'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Card(
            elevation: 1,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Card widget, elevation 1'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Card(
            elevation: 4,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Card widget, elevation 4'),
              ),
            ),
          ),
          const SizedBox(height: 10),
          const Card(
            elevation: 8,
            child: SizedBox(
              height: 50,
              child: Center(
                child: Text('Card widget, elevation 8'),
              ),
            ),
          ),
          const Divider(),
        ],
      ),
    );
  }
}

/// Widget used to toggle the theme style of the application.
@immutable
class ThemeModeSwitch extends StatelessWidget {
  const ThemeModeSwitch({
    Key? key,
    required this.themeMode,
    required this.onChanged,
  }) : super(key: key);
  final ThemeMode themeMode;
  final ValueChanged<ThemeMode> onChanged;

  @override
  Widget build(BuildContext context) {
    final List<bool> isSelected = <bool>[
      themeMode == ThemeMode.light,
      themeMode == ThemeMode.system,
      themeMode == ThemeMode.dark,
    ];
    return ToggleButtons(
      isSelected: isSelected,
      onPressed: (int newIndex) {
        if (newIndex == 0) {
          onChanged(ThemeMode.light);
        } else if (newIndex == 1) {
          onChanged(ThemeMode.system);
        } else {
          onChanged(ThemeMode.dark);
        }
      },
      children: const <Widget>[
        Icon(Icons.wb_sunny),
        Icon(Icons.phone_iphone),
        Icon(Icons.bedtime),
      ],
    );
  }
}

// Draw a number of boxes showing the colors of key theme color properties
// in the ColorScheme of the inherited ThemeData and some of its key color
// properties.
// This widget is just used so we can visually see the active theme colors
// in the examples and their used FlexColorScheme based themes.
class ShowThemeColors extends StatelessWidget {
  const ShowThemeColors({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    final ThemeData theme = Theme.of(context);
    final ColorScheme colorScheme = theme.colorScheme;
    final Color appBarColor =
        theme.appBarTheme.backgroundColor ?? theme.primaryColor;

    // A Wrap widget is just the right handy widget for this type of
    // widget to make it responsive.
    return Wrap(
      spacing: 4,
      runSpacing: 4,
      crossAxisAlignment: WrapCrossAlignment.center,
      children: <Widget>[
        ThemeCard(
          label: 'Primary',
          color: colorScheme.primary,
          textColor: colorScheme.onPrimary,
        ),
        ThemeCard(
          label: 'Primary\nColor',
          color: theme.primaryColor,
          textColor: theme.primaryTextTheme.subtitle1!.color ?? Colors.white,
        ),
        ThemeCard(
          label: 'Primary\nColorDark',
          color: theme.primaryColorDark,
          textColor:
              ThemeData.estimateBrightnessForColor(theme.primaryColorDark) ==
                      Brightness.dark
                  ? Colors.white
                  : Colors.black,
        ),
        ThemeCard(
          label: 'Primary\nColorLight',
          color: theme.primaryColorLight,
          textColor:
              ThemeData.estimateBrightnessForColor(theme.primaryColorLight) ==
                      Brightness.dark
                  ? Colors.white
                  : Colors.black,
        ),
        ThemeCard(
          label: 'Secondary\nHeader',
          color: theme.secondaryHeaderColor,
          textColor: ThemeData.estimateBrightnessForColor(
                      theme.secondaryHeaderColor) ==
                  Brightness.dark
              ? Colors.white
              : Colors.black,
        ),
        ThemeCard(
          label: 'Primary\nVariant',
          color: colorScheme.primaryVariant,
          textColor: ThemeData.estimateBrightnessForColor(
                      colorScheme.primaryVariant) ==
                  Brightness.dark
              ? Colors.white
              : Colors.black,
        ),
        ThemeCard(
          label: 'Secondary',
          color: colorScheme.secondary,
          textColor: colorScheme.onSecondary,
        ),
        ThemeCard(
          label: 'Toggleable\nActive',
          color: theme.toggleableActiveColor,
          textColor: ThemeData.estimateBrightnessForColor(
                      theme.toggleableActiveColor) ==
                  Brightness.dark
              ? Colors.white
              : Colors.black,
        ),
        ThemeCard(
          label: 'Secondary\nVariant',
          color: colorScheme.secondaryVariant,
          textColor: ThemeData.estimateBrightnessForColor(
                      colorScheme.secondaryVariant) ==
                  Brightness.dark
              ? Colors.white
              : Colors.black,
        ),
        ThemeCard(
          label: 'AppBar',
          color: appBarColor,
          textColor: ThemeData.estimateBrightnessForColor(appBarColor) ==
                  Brightness.dark
              ? Colors.white
              : Colors.black,
        ),
        ThemeCard(
          label: 'Bottom\nAppBar',
          color: theme.bottomAppBarColor,
          textColor:
              ThemeData.estimateBrightnessForColor(theme.bottomAppBarColor) ==
                      Brightness.dark
                  ? Colors.white
                  : Colors.black,
        ),
        ThemeCard(
          label: 'Divider',
          color: theme.dividerColor,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Background',
          color: colorScheme.background,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Canvas',
          color: theme.canvasColor,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Surface',
          color: colorScheme.surface,
          textColor: colorScheme.onSurface,
        ),
        ThemeCard(
          label: 'Card',
          color: theme.cardColor,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Dialog',
          color: theme.dialogBackgroundColor,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Scaffold\nbackground',
          color: theme.scaffoldBackgroundColor,
          textColor: colorScheme.onBackground,
        ),
        ThemeCard(
          label: 'Error',
          color: colorScheme.error,
          textColor: colorScheme.onError,
        ),
      ],
    );
  }
}

// This is just simple SizedBox with a Card with a passed in label, background
// and text label color. Used to show the colors of a theme color property.
class ThemeCard extends StatelessWidget {
  const ThemeCard({
    Key? key,
    required this.label,
    required this.color,
    required this.textColor,
  }) : super(key: key);

  final String label;
  final Color color;
  final Color textColor;

  @override
  Widget build(BuildContext context) {
    return SizedBox(
      height: 50,
      width: 85,
      child: Card(
        margin: EdgeInsets.zero,
        shape: RoundedRectangleBorder(
          borderRadius: BorderRadius.circular(4),
          side: BorderSide(
            color: Theme.of(context).dividerColor,
          ),
        ),
        elevation: 0,
        color: color,
        child: Center(
          child: Text(
            label,
            style: TextStyle(color: textColor, fontSize: 12),
            textAlign: TextAlign.center,
          ),
        ),
      ),
    );
  }
}

Here we see that we get a flat uniform color, despite different elevation, with Material of type canvas:

The example is using slightly different color for surface and background in its dark theme:
        background: Color.alphaBlend(
            kDarkPrimary.withAlpha(0x25), const Color(0xff121212)),
        surface: Color.alphaBlend(
            kDarkPrimary.withAlpha(0x40), const Color(0xff121212)),

If we change the background color to use the same color definition as the surface color:
        background: Color.alphaBlend(
            kDarkPrimary.withAlpha(0x40), const Color(0xff121212)),
        surface: Color.alphaBlend(
            kDarkPrimary.withAlpha(0x40), const Color(0xff121212)),

then we get overlay color on them too, as seen here:

We expected overlay color also when background was using the slightly darker color branded background color
Color.alphaBlend(kDarkPrimary.withAlpha(0x25), const Color(0xff121212)), it should actually have looked like this:
Expected result:

NOTE: This example exaggerates the differences one might use in a real design, between the background and surface colors, just to show the issue visually in a more pronounced way.

Cause of issue
The lack of overlay color on the Material of type canvas in the issue case, is caused by the applyOverlay color function.
The applyOverlay function is used by the framework to apply the overlay color if theme specified it should be used, and if we are in dark mode. It also checks if the used color without opacity, is the surface color, and only then applies it.
  static Color applyOverlay(BuildContext context, Color color, double elevation) {
    final ThemeData theme = Theme.of(context);
    if (elevation > 0.0 &&
        theme.applyElevationOverlayColor &&
        theme.brightness == Brightness.dark &&
        color.withOpacity(1.0) == theme.colorScheme.surface.withOpacity(1.0)
    ) {
      return colorWithOverlay(color, theme.colorScheme.onSurface, elevation);
    }
    return color;
  }

However, since Material, when it is of type canvas, is actually using the colorScheme.background as its themed color, it will not get any elevation overlay color if the theme specifies background and surface colors that differs slightly from each other.
This situation typically occurs when making color branded surfaces and backgrounds, and one uses slightly different color branded strengths for these colors. This type of color branding is more common on desktop and web designs, but might find more uses on devices with Material V3 as well.
The current behavior in Flutter prevents us from using more nuanced color branded surfaces, where surface and background colors use slightly different dark color branded strengths, while retaining the nice elevation overlay on Material of type canvas.
The current behavior also creates a situation where sometimes themed Material of type canvas, gets overlay color applied when so defined and as expected, but sometimes it does not. Either it should never get it, or always, when Material of type card gets it as well. Not as now, only "sometimes", ie when the background color happens to be using a themed color, that happens to be equal to themed surface color.
It is worth noticing that if for some reason Material design spec would call for that Material of type canvas should never get overlay color applied in dark mode for elevations, then widgets like Drawer and BottomNavigationBar would not get it either. I don't think that is the intent.
Solution proposal
Consider adding a check to see if we are using the surface or background color to the applyOverlay function:
  static Color applyOverlay(BuildContext context, Color color, double elevation) {
    final ThemeData theme = Theme.of(context);
    if (elevation > 0.0 &&
        theme.applyElevationOverlayColor &&
        theme.brightness == Brightness.dark &&
        (color.withOpacity(1.0) == theme.colorScheme.surface.withOpacity(1.0) ||
         color.withOpacity(1.0) == theme.colorScheme.background.withOpacity(1.0)
        )
    ) {
      return colorWithOverlay(color, theme.colorScheme.onSurface, elevation);
    }
    return color;
  }

The above modification makes the applyOverlay color function work correctly with Material, also when using color branded themes where the themed colors colorScheme.surface and colorScheme.background differ slightly from each other.
The above code change was used to produce the earlier visual presentation of the expected outcome above.
Pull request
I'm willing to submit a pull request with this fix, if this solution is considered acceptable.

Flutter doctor
[√] Flutter (Channel master, 2.6.0-6.0.pre.147, on Microsoft Windows [Version 10.0.19041.1237], locale en-US)
    • Flutter version 2.6.0-6.0.pre.147 at C:\Users\mryds\fvm\versions\master
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 83dfb2237a (2 days ago), 2021-09-17 23:48:04 -0400
    • Engine revision 31792e0340
    • Dart version 2.15.0 (build 2.15.0-120.0.dev)

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at C:\Users\mryds\AppData\Local\Android\sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.10.4)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.10.31515.178
    • Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 2020.3)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[√] IntelliJ IDEA Community Edition (version 2021.2)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2018.3.1
    • Flutter plugin version 60.1.4
    • Dart plugin version 212.5284.31

[√] VS Code (version 1.60.0)
    • VS Code at C:\Users\mryds\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.25.0

[√] Connected device (5 available)
    • SM T510 (mobile)                 • R52N906MLAV   • android-arm    • Android 11 (API 30)
    • sdk gphone x86 64 arm64 (mobile) • emulator-5554 • android-x64    • Android 11 (API 30) (emulator)
    • Windows (desktop)                • windows       • windows-x64    • Microsoft Windows [Version 10.0.19041.1237]
    • Chrome (web)                     • chrome        • web-javascript • Google Chrome 93.0.4577.82
    • Edge (web)                       • edge          • web-javascript • Microsoft Edge 93.0.961.52

• No issues found!

Author's observations can be reproduced with samples provided on stable and master.

 screenshots
ok sample

fail sample

flutter doctor -v
[✓] Flutter (Channel master, 2.6.0-6.0.pre.147, on macOS 11.5.1 20G80 darwin-arm, locale en-GB)
    • Flutter version 2.6.0-6.0.pre.147 at /Users/nexus/dev/sdks/flutters
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 83dfb2237a (2 days ago), 2021-09-17 23:48:04 -0400
    • Engine revision 31792e0340
    • Dart version 2.15.0 (build 2.15.0-120.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/nexus/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.5.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • CocoaPods version 1.11.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

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

[✓] Connected device (3 available)
    • M2007J20CG (mobile) • 5dd3be00 • android-arm64  • Android 11 (API 30)
    • macOS (desktop)     • macos    • darwin-arm64   • macOS 11.5.1 20G80 darwin-arm
    • Chrome (web)        • chrome   • web-javascript • Google Chrome 93.0.4577.82

• No issues found!

[✓] Flutter (Channel stable, 2.5.1, on macOS 11.5.1 20G80 darwin-arm, locale en-GB)
    • Flutter version 2.5.1 at /Users/nexus/dev/sdks/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision ffb2ecea52 (3 days ago), 2021-09-17 15:26:33 -0400
    • Engine revision b3af521a05
    • Dart version 2.14.2

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/nexus/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5.1, Build version 12E507
    • CocoaPods version 1.11.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

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

[✓] Connected device (3 available)
    • M2007J20CG (mobile) • 5dd3be00 • android-arm64  • Android 11 (API 30)
    • macOS (desktop)     • macos    • darwin-arm64   • macOS 11.5.1 20G80 darwin-arm
    • Chrome (web)        • chrome   • web-javascript • Google Chrome 93.0.4577.82

• No issues found!

Thanks @danagbemava-nc for the triage.
Now let's see what the Flutter Material design experts thinks.
Personally I think it is just an oversight that the line with the or comparison with the background color:
color.withOpacity(1.0) == theme.colorScheme.background.withOpacity(1.0)

is missing from the applyOverlayColor function here.
It is not a common use cases on mobile devices, maybe a bit with tablets. However with the arrival of Material V3 (You) I think this kind of usage and need will increase on mobile devices too.
This type of usage, and the demonstrated issue, only becomes visible when using color branded surface and background colors that differs from each other slightly. This is currently more commonly used for designs on Web and Desktop. When using it, it is rather important that the overlay color in dark mode also works when surface and background colors differ from each other slightly, for the right effect on all Widgets using Material of type canvas in Flutter.
I have no idea how the Flutter Material team intends to support the beautiful color branded themes we have seen in Material V3 (You) examples, but this fix will enable more nuanced support for it, using already existing features in Flutter.

Thanks @danagbemava-nc for the typo corrections in the issue description.
I was looking for some tests for ElevationOverlay.applyOverlay but failed to locate any.
I wrote the passing and failing tests for the ElevationOverlay.applyOverlay function, with respect to how it it would be expected to behave, with light and dark theme mode that uses ThemeData.applyElevationOverlayColor: true by using default ThemeData.from(colorScheme: ColorScheme.light()) for light theme and ThemeData.from(colorScheme: ColorScheme.dark()) for dark theme.
The tests show how ElevationOverlay.applyOverlay correctly never applies elevation in light theme mode, but does so in dark theme mode when there is elevation, and that the elevation overlay color is applied for both colorScheme.background and colorScheme.surface color, as long as they are both using the same color.
If a dark theme is created this way, it means that elevated Material widgets of both type MaterialType.canvas and MaterialType.card will get elevationOverlay applied correctly.
This is because with this theme creation method:

MaterialType.canvas uses theme.canvasColor, that is set to is theme.colorScheme.background color as its default color.
MaterialType.card uses theme.cardColor, that is set to is theme.colorScheme.surfaceColor as its default color.

and in a default theme, both these ColorScheme colors happens to be equal.
The result is that in dark mode Widgets that use Material of type canvas like Dialogs, Drawer, BottomNavigationBar will get elevationOverlay applied in dark mode, as they should.
The tests that fail in this test suite, are the last Expect in F) and last Expect in G).
In failing part of test F) it is tested what happens when we use ThemeData.from() but have different colors on colorScheme.background and colorScheme.surface.
Currently elevationOverlay will then not be applied to widgets using Material of type canvas. This results in that in dark mode
e.g. Dialogs, Drawer, BottomNavigationBar will now suddenly not get any elevationOverlay color applied in dark mode, even if so requested, but they should. This looks very poor as demonstrated visually above in original issue post.
In failing part of test G) the same situation is demonstrated by using the older default ThemeData() factory and creating the dark theme with:
ThemeData dark = ThemeData(
  brightness: Brightness.dark,
  applyElevationOverlayColor: true,
);

We request applyElevationOverlayColor but still widgets like Dialogs, Drawer, BottomNavigationBar will not get elevationOverlay applied in dark mode, even if requested and even if they should. This is because the ThemeData() factory with Brightness.dark actually creates ThemeData where:
theme.colorScheme.background = Colors.grey[700]
theme.colorScheme.surface = Colors.grey[800]
theme.canvasColor = Colors.grey[850]
theme.cardColor = Colors.grey[800];
theme.backgroundColor = Colors.grey[700];
theme.dialogBackgroundColor = Colors.grey[800];

Creating a situation where very few surfaces that are elevated, will actually get any elevationOverlay color applied even if it was so requested.
It is correct that the Material Design Guide states that the semi-transparent color should use the onSurface color for the overlay color on surfaces. This is fine and will work correctly in dark mode despite difference in actual used dark surface colors. However, nowhere is it stated in the guide that elevated Material surfaces are only represented by the in Flutter called ColorScheme.surface color. Themed Material surfaces in Flutter can have many different colors, most notably:

Material of type canvas, that uses theme.canvasColor (that in a ThemeData.from is set to colorScheme.background, but may also use other themed colors in ThemeData() factory)
Material of type card that uses theme.cardColor  (that in a ThemeData.from is set to colorScheme.surface, but may also use other themed colors in ThemeData() factory)
Dialogs uses theme.dialogBackgroundColor (that in a ThemeData.from is set to colorScheme.background, but may also use other themed colors in ThemeData() factory)

These are still all Material surfaces that can be elevated all needs to get elevationOverlay color applied in dark mode, when so requested.
That these elevated Material surfaces in Flutter, refer to their themed surface background colors with some other name than "surface", is an implementation detail in Flutter.
For correct elevationOverlay behavior in dark mode, these surface colors, when used on Material, should all get elevationOverlay color applied when so defined.

theme.colorScheme.background
theme.colorScheme.surface
theme.canvasColor
theme.cardColor
theme.backgroundColor
theme.dialogBackgroundColor

This would ensure correct dark mode elevation behavior when using ThemeData.applyElevationOverlayColor: true and using themes created with ThemeData.from() that may also use slightly different background and surface colors, as well as when creating ThemeData with the factory ThemeData() that may have even more nuanced differences in themed dark surface colors.
Tests for ThemeData and ElevationOverlay.applyOverlay
The tests below includes tests that pass and are OK, as well as two failing tests that should pass.
Considering all the above colors that should also be surface colors on Material, there are more failing test cases that could be written. Modifying the tests to actually use Material and test weather it gets an overlay applied or not, when using different theming methods, would be even better than these tests. These are still a bit simplified widget plus unit tests. I can certainly improve them for a PR with a fix.
These test on purpose do not verify the actual resulting elevationOverlay color, only if we got an overlay color when we should get one.

TESTS: ThemeData and ElevationOverlay.applyOverlay
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';

void main() {
  group('Test ElevationOverlay.applyOverlay', () {
    late BuildContext savedContext;
    Widget testApp(
      ThemeMode themeMode,
      ThemeData lightTheme,
      ThemeData darkTheme,
    ) {
      return MaterialApp(
        theme: lightTheme,
        darkTheme: darkTheme,
        themeMode: themeMode,
        home: Builder(
          builder: (BuildContext context) {
            savedContext = context;
            return Container();
          },
        ),
      );
    }

    ThemeData lightTheme(int surfaceBlend, int backgroundBlend) =>
        ThemeData.from(
          colorScheme: ColorScheme.light(
            surface: Color.alphaBlend(
                const ColorScheme.light().primary.withAlpha(surfaceBlend),
                const ColorScheme.light().surface),
            background: Color.alphaBlend(
                const ColorScheme.light().primary.withAlpha(backgroundBlend),
                const ColorScheme.light().background),
          ),
        );

    ThemeData darkTheme(int surfaceBlend, int backgroundBlend) =>
        ThemeData.from(
          colorScheme: ColorScheme.dark(
            surface: Color.alphaBlend(
                const ColorScheme.dark().primary.withAlpha(surfaceBlend),
                const ColorScheme.dark().surface),
            background: Color.alphaBlend(
                const ColorScheme.dark().primary.withAlpha(backgroundBlend),
                const ColorScheme.dark().background),
          ),
        );

    testWidgets(
        'A) Expect no overlay in light ThemeData.from with default background '
        'and surface colors.', (WidgetTester tester) async {
      // Default and equal surface and background colors.
      final ThemeData light = lightTheme(0x00, 0x00);
      final ThemeData dark = darkTheme(0x00, 0x00);

      await tester.pumpWidget(testApp(ThemeMode.light, light, dark));

      final Color surface = Theme.of(savedContext).colorScheme.surface;
      final Color background = Theme.of(savedContext).colorScheme.background;

      // EXPECT: no elevation overlay color for none elevated surface.
      expect(surface,
          equals(ElevationOverlay.applyOverlay(savedContext, surface, 0)));
      // EXPECT: no elevation overlay color for elevated surface.
      expect(surface,
          equals(ElevationOverlay.applyOverlay(savedContext, surface, 1)));

      // EXPECT: no elevation overlay color for none elevated background.
      expect(background,
          equals(ElevationOverlay.applyOverlay(savedContext, background, 0)));
      // EXPECT: no elevation overlay color for elevated background.
      expect(background,
          equals(ElevationOverlay.applyOverlay(savedContext, background, 1)));
    });

    testWidgets(
        'B) Expect no overlay in light ThemeData.from with background '
        'and surface colors using same none default color.',
        (WidgetTester tester) async {
      // None default surface and background colors, but equal.
      final ThemeData light = lightTheme(0x10, 0x10);
      final ThemeData dark = darkTheme(0x10, 0x10);

      await tester.pumpWidget(testApp(ThemeMode.light, light, dark));

      final Color surface = Theme.of(savedContext).colorScheme.surface;
      final Color background = Theme.of(savedContext).colorScheme.background;

      // EXPECT: no elevation overlay color for none elevated surface.
      expect(surface,
          equals(ElevationOverlay.applyOverlay(savedContext, surface, 0)));
      // EXPECT: no elevation overlay color for elevated surface.
      expect(surface,
          equals(ElevationOverlay.applyOverlay(savedContext, surface, 1)));

      // EXPECT: no elevation overlay color for none elevated background.
      expect(background,
          equals(ElevationOverlay.applyOverlay(savedContext, background, 0)));
      // EXPECT: no elevation overlay color for elevated background.
      expect(background,
          equals(ElevationOverlay.applyOverlay(savedContext, background, 1)));
    });

    testWidgets(
        'C) Expect no overlay in light ThemeData.from with background '
        'and surface colors using different none default color.',
        (WidgetTester tester) async {
      // None default and not equal surface and background colors.
      final ThemeData light = lightTheme(0x10, 0x20);
      final ThemeData dark = darkTheme(0x10, 0x20);

      await tester.pumpWidget(testApp(ThemeMode.light, light, dark));

      final Color surface = Theme.of(savedContext).colorScheme.surface;
      final Color background = Theme.of(savedContext).colorScheme.background;

      // EXPECT: no elevation overlay color for none elevated surface.
      expect(surface,
          equals(ElevationOverlay.applyOverlay(savedContext, surface, 0)));
      // EXPECT: no elevation overlay color for elevated surface.
      expect(surface,
          equals(ElevationOverlay.applyOverlay(savedContext, surface, 1)));

      // EXPECT: no elevation overlay color for none elevated background.
      expect(background,
          equals(ElevationOverlay.applyOverlay(savedContext, background, 0)));
      // EXPECT: no elevation overlay color for elevated background.
      expect(background,
          equals(ElevationOverlay.applyOverlay(savedContext, background, 1)));
    });

    testWidgets(
        'D) Expect overlay in dark ThemeData.from with default background '
        'and surface colors, when elevation > 0.', (WidgetTester tester) async {
      // Default and equal surface and background colors.
      final ThemeData light = lightTheme(0x00, 0x00);
      final ThemeData dark = darkTheme(0x00, 0x00);

      await tester.pumpWidget(testApp(ThemeMode.dark, light, dark));

      final Color surface = Theme.of(savedContext).colorScheme.surface;
      final Color background = Theme.of(savedContext).colorScheme.background;

      // EXPECT: no elevation overlay color for none elevated surface.
      expect(surface,
          equals(ElevationOverlay.applyOverlay(savedContext, surface, 0)));
      // EXPECT: elevation overlay color for elevated surface.
      expect(surface,
          isNot(ElevationOverlay.applyOverlay(savedContext, surface, 1)));

      // EXPECT: no elevation overlay color for none elevated background.
      expect(background,
          equals(ElevationOverlay.applyOverlay(savedContext, background, 0)));
      // EXPECT: elevation overlay color for elevated background.
      expect(background,
          isNot(ElevationOverlay.applyOverlay(savedContext, background, 1)));
    });

    testWidgets(
        'E) Expect overlay in dark ThemeData.from with background and surface '
        'colors using same none default color, when elevation > 0.',
        (WidgetTester tester) async {
      // None default surface and background colors, but equal.
      final ThemeData light = lightTheme(0x10, 0x10);
      final ThemeData dark = darkTheme(0x10, 0x10);

      await tester.pumpWidget(testApp(ThemeMode.dark, light, dark));

      final Color surface = Theme.of(savedContext).colorScheme.surface;
      final Color background = Theme.of(savedContext).colorScheme.background;

      // EXPECT: no elevation overlay color for none elevated surface.
      expect(surface,
          equals(ElevationOverlay.applyOverlay(savedContext, surface, 0)));
      // EXPECT: elevation overlay color for elevated surface.
      expect(surface,
          isNot(ElevationOverlay.applyOverlay(savedContext, surface, 1)));

      // EXPECT: no elevation overlay color for none elevated background.
      expect(background,
          equals(ElevationOverlay.applyOverlay(savedContext, background, 0)));
      // EXPECT: elevation overlay color for elevated background.
      expect(background,
          isNot(ElevationOverlay.applyOverlay(savedContext, background, 1)));
    });

    testWidgets(
        'F) Expect overlay in dark ThemeData.from with background and surface '
        'colors using separate and none default color, when elevation > 0.',
        (WidgetTester tester) async {
      // None default and not equal surface and background colors.
      final ThemeData light = lightTheme(0x10, 0x20);
      final ThemeData dark = darkTheme(0x10, 0x20);

      await tester.pumpWidget(testApp(ThemeMode.dark, light, dark));

      final Color surface = Theme.of(savedContext).colorScheme.surface;
      final Color background = Theme.of(savedContext).colorScheme.background;

      // EXPECT: no elevation overlay color for none elevated surface.
      expect(surface,
          equals(ElevationOverlay.applyOverlay(savedContext, surface, 0)));
      // EXPECT: elevation overlay color for elevated surface.
      expect(surface,
          isNot(ElevationOverlay.applyOverlay(savedContext, surface, 1)));

      // EXPECT: no elevation overlay color for none elevated background.
      expect(background,
          equals(ElevationOverlay.applyOverlay(savedContext, background, 0)));
      // EXPECT: elevation overlay color for elevated background.
      expect(background,
          isNot(ElevationOverlay.applyOverlay(savedContext, background, 1)));
    });

    testWidgets(
        'G) Expect overlay in dark ThemeData() on background and surface '
        'colors when using default ThemeData() factory with '
        'applyElevationOverlayColor = true.', (WidgetTester tester) async {
      // Light and dark theme data made using
      // ThemeData(applyElevationOverlayColor: true) factory.
      final ThemeData light = ThemeData(applyElevationOverlayColor: true);
      final ThemeData dark = ThemeData(
        brightness: Brightness.dark,
        applyElevationOverlayColor: true,
      );

      await tester.pumpWidget(testApp(ThemeMode.dark, light, dark));

      final Color surface = Theme.of(savedContext).colorScheme.surface;
      final Color background = Theme.of(savedContext).colorScheme.background;

      // EXPECT: no elevation overlay color for none elevated surface.
      expect(surface,
          equals(ElevationOverlay.applyOverlay(savedContext, surface, 0)));
      // EXPECT: elevation overlay color for elevated surface.
      expect(surface,
          isNot(ElevationOverlay.applyOverlay(savedContext, surface, 1)));

      // EXPECT: no elevation overlay color for none elevated background.
      expect(background,
          equals(ElevationOverlay.applyOverlay(savedContext, background, 0)));
      // EXPECT: elevation overlay color for elevated background.
      expect(background,
          isNot(ElevationOverlay.applyOverlay(savedContext, background, 1)));
    });
  });
}

Summary
Why is is the current implementation problematic?
It prevents creation of more nuanced themed dark modes, where Flutter Material using built in Widgets, that use different ThemeData background color properties for their used elevated Material surface, would actually get an elevation overlay color applied when setting ThemeData.applyElevationOverlayColor: true.
For a more correct, Material Design based dark mode, when using such nuanced dark themes, the dark surfaces with slightly differing primary color blended surface colors, should also get elevation color overlay applied.
If current built in Flutter Widgets use a default themed color, that is not equal to colorScheme.surface the elevation overlay color is never applied. Many built in widgets that use Material, actually use some other color than colorScheme.surface as their themed background color.
This creates challenges and limitations when using more nuanced dark themes, when using slight variations for different Material background colors in such dark themes. One can still create such themes, but they do not get correct elevation overlays applied in dark mode. The only way to get it applied, is if the same primary color branded blend strength is used on all the different background related ThemeData color properties , that Material using Widgets that support elevation use.
They must all be set to the same color as used on colorScheme.surface, creating severe limitations into the nuances that dark mode branded color themes can use.
A more complete applyOverlay function
A version of the applyOverlay function that correctly considers all background colors, that built in Widgets that use elevated Material may have, when created either with the ThemeData() or ThemeData.from() factory could look like this:
  static Color applyOverlay(BuildContext context, Color color, double elevation) {
    final ThemeData theme = Theme.of(context);
    final Color opaqueColor = color.withAlpha(255);
    final bool isSurfaceColor =
        opaqueColor == theme.colorScheme.surface.withAlpha(255) ||
        opaqueColor == theme.colorScheme.background.withAlpha(255) ||
        opaqueColor == theme.backgroundColor.withAlpha(255) ||
        opaqueColor == theme.canvasColor.withAlpha(255) ||
        opaqueColor == theme.cardColor.withAlpha(255) ||
        opaqueColor == theme.dialogBackgroundColor.withAlpha(255);

    if (elevation > 0.0 &&
        theme.applyElevationOverlayColor &&
        theme.brightness == Brightness.dark &&
        isSurfaceColor) {
      return colorWithOverlay(color, theme.colorScheme.onSurface, elevation);
    }
    return color;
  }

Using the above function, built-in Widgets that depend on Material will receive all receive overlay elevation color in dark mode, when so requested, even if each property would have a slightly different primary color branded color using minor variations in alpha blend strengths.
Next steps

I will make better and more complete tests, for passing and failing cases.
I will investigate what current tests, if any, using the above function would break.
I will wait to see what changes Material 3 (Material You) brings to the table.
If breaks are very few or none, and Material 3 does not bring any solution to this, I will submit a PR for review.

Based on visuals and examples seen from Material 3 in Android 12. Material 3 uses surfaces with alpha blends of primary and variant colors. Thus it might be that Material 3 will bring some changes to this behavior as well.


feat(ViewEngineHooksResource): Enable registering ViewEngineHooks by convention

A ViewEngineHooks object can now be registered by either

Creating a {Name}ViewEngineHooks class that implements ViewEngineHooks
Decorating a class that implements ViewEngineHooks with @viewEngineHooks

and

Registering that class with the view via a  tag
Configuring the class as a globalResource

Did You include dist folder by accident?

You're right I did.


feature: rules and regulations feature

Description
Added rules and regulation on joining as new member feature. New service, controller and constants folder added
Fixes # (issue)
1-feature-rules_and_regulations #1
Type of change
Please delete options that are not relevant.

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

Dependencies
no additional dependencies
For example

react-native : 1.02

Native Dependencies
please note down the native dependencies that use in this code change. Which can have issues with code push
For example

react-native : 1.02

checklist

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

bro on the md file dependency as react native

on the merge request


param mode not working ?

hi, don´t know if this is a web api thing or a bug of this project.
everytime a upload files with a mode, the mode (blue label) does not appear in the jscrambler project web-frontend... so in fact i don´t know if mode is really sent...i tried via config and cli parameter...
in every case the mode label is missing...

It's a bug of the Frontend, here's a statement from the support:
Hi,
I've tested it and the application mode is applied but for some reason the Website is not showing it. The issue has been reported and as soon as it is fixed we'll let you know.
Thank you.

Update from the support:
Hi,
Just to let you know that the problem has been fixed though the problem was indeed related with the Web API not considering the application mode and not a problem with the Website interface not displaying it.
Thank you.

Glad everything is fine as of now :+1:


Set refactored functionality to skip dumping values that have already been dumped somewhere else, not just properties that are the same as the current object.

Currently we only prevent attempting to dump a static property that represents the current object. This scenario is typically for singleton values, such as the Options class with the Options.Instance property.


Support specifying Node Affinity for CephToolbox pod

This will allow the CephToolbox pod to get scheduled on specific node.
https://bugzilla.redhat.com/show_bug.cgi?id=2249640

/retest

/hold

/retest

/retest

We are again seeing the noobaa error where noobaa used to stay struck in configuring phase forever
~ $ oc get noobaa
NAME     S3-ENDPOINTS                    STS-ENDPOINTS                   IMAGE                                        PHASE         AGE
noobaa   ["https://<IP_ADDRESS>:31195"]   ["https://<IP_ADDRESS>:32707"]   quay.io/noobaa/noobaa-core:master-20240108   Configuring   4m59s

/retest

/unhold

/cherry-pick release-4.16


Should gather() add a vinyl object to the stream ?

I was thinking of using this on a project, but I want to pipe the lcov file to coveralls, not just consume it in format() - but the object put into the stream by gather() isn't a vinyl file object.  This breaks all the downstream plugins I've tried to use with it.
Any objection to me submitting a PR for this - making the thing passed between the separate plugins a vinyl object?
Any problem you would see with doing this?  You've modified the lcov format, do you think it would still work with other reporting tools like coveralls?

Is this what you mean
https://github.com/dylanb/gulp-coverage/blob/master/gulpfile.js#L71

Oh cool - so the reporter has an lcov output, I wasn't aware that you had an lcov formatter and assumed I had to use the json added to the stream by gather().
That fixes my problem thanks!
If you treat gather as an isolated plugin through, it breaks gulp conventions by not adding a vinyl file object to the stream - but if format() does then this is not such a big deal since no-one is going to consume the output of gather directly.


e2e: add test for BackendTrafficPolicy retry

Fixes: https://github.com/envoyproxy/gateway/issues/2679

Very nice addition! I think that a lot of features that are difficult to verify with assertions on an HTTP requests/responses will benefit from metrics-based validation.


additional aliases for docker commands

[ ] dexp for docker exec greped by container
[ ] dstopp for docker stop greped by container

document the README.md as well

@thsutton if you feel like it


Add fake rate and duplicate rate plots to the benchmarking scripts

CPU benchmark points are updated.
Fake rate and duplicate rate plots for the Track Candidate is included.
with -l option one can also write out lower level objects efficiency/duplicate/fakerate plots for T4+T4x, and T3. (pT4 not included yet)
with -w option (0 or 1) one can control whether to write the output ntuple or not. -w 0 will turn it off and speed things up for timing result studies.
bin/sdl.cc now contains the main running workflow (runMD, runT4, etc. etc.) so that the developer can focus on one file to get the overview instead of looking at two different places.
code/core/write_sdl_ntuple.cc only contains ntuple writing related functions.
... And some other changes that I can't remember off the top of my head as I am writing this PR

was there a reason you changed " (ana.verbose == 1) " to " (ana.verbose >= 1) " in trkCore?


Pylance issue

 Environment data

Language Server version: 2024.9.1
OS and version: darwin arm64
Python version (and distribution if applicable, e.g. Anaconda):
python.analysis.indexing: true
python.analysis.typeCheckingMode: off

 Code Snippet

XXX

 Repro Steps

XXX

 Expected behavior
XXX
 Actual behavior
XXX
 Logs

XXX

Thanks for logging an issue.
Unfortunately, we need more information to figure out what your problem is.
Please enter the information as described here:
https://github.com/microsoft/pylance-release/blob/main/TROUBLESHOOTING.md#filing-an-issue


Path string

This pull request closes #5.

It contains PathString (#5)
and other extra build tools enabled (for GitHub release, Coveralls, etc.)

Changes Unknown when pulling 742c3bf9b43f5db756187d4f922adce11dd322ce on path-string into ** on release**.

Changes Unknown when pulling 742c3bf9b43f5db756187d4f922adce11dd322ce on path-string into ** on release**.


OC11/GDPR

Things to do:

[ ] have a CLI command to delete/anonymize a given user (right to be forgotten)
[ ] ensure logs are kept for the already decided amount of time
[ ] if easy, from the profile page, allow users to download their own data (using the same queries implemented for EDH)

See https://github.com/inveniosoftware/invenio-app-ils/issues/925


Local images are not loaded properly.

When using an internal image like so
the gfm previewer does not show the image in the intellij plugin

However, when using a markdown plugin for firefox, the image is visible properly like so -

However, when using the absolute path instead of relative path the image is visible.
Using absolute path -

the image is visible.

:+1:

I have the same problem that local relative links does not work in the preview.

This would be really useful - it works on GitHub, so it would be natural to expect it to work here as well.

What's the status of this? Is there any plan to support this?

It will be supported in next release. It's scheduled on February 5th.

@ShyykoSerhiy I made a pull request for this, https://github.com/ShyykoSerhiy/gfm-plugin/pull/119. Could you have a look when you are available? Thanks!

That's awesome.

fixed by https://github.com/ShyykoSerhiy/gfm-plugin/pull/119


Add ability to set redirect URLs

After login and register.  More than happy to build this if you can let me know how you'd prefer it to work.

I think this should be an option for SimpleUser under $app['user.options']. And then this could be re-used in the $app['security.firewalls'] when specifying the default_target_path.

That will be useful !


Cluster high availability issue

Dear friends,
let me describe a recent problem with vernemq running in cluster environment.
I have a cluster consisting of 3 nodes which run vernemq configured against documentation https://verne.mq/docs/clustering.html.
When all nodes are up, it works ("vmq-admin cluster status" says so).

If I pub, sub to each node, it works.
Even if I put layer 4 LB before the cluster, it works.

BUT as soon as I stop vernemq service on one (no matter which) node (I can see the running status of that node as false using "vmq-admin cluster status") THEN I can't pub/sub to any of the remaining nodes. When I turn the vernemq service back on, the vernemq service is available on every node back again.
Is it a misconfiguration problem or haven't anyone experienced similar behaviour?

Heya,
thanks so much for checking out VerneMQ :)
Look at the Dealing with Network partitions part in the clustering guide: clustering guide
in short: it's intended, but look at trade_consistency = on setting.

Hi, thank you. Maybe I understand better. But still don't understand what's the purpose of such behaviour? If I want a highly available MQTT cluster to ensure that my clients will always connect, even though one of the nodes are down, how to achieve this with VerneMQ then?

Hi Slavomir,
sorry for my incomplete answer! The context here is the MQTT protocol itself, it's hard to make it distributable.
To achieve what you want, you'd have to set allow_multiple_sessions = on, in addition to trade_consistency.
Against the MQTT spec, you could end up having multiple sessions for the same client ID in that case.
tradeoffs, tradeoffs ;)

I suppose allow_multiple_sessions=on is working for you.
Feel free to re-open the issue in case of need.

Hey, I wanted to thank you for the great answer on my questions.
I was wondering, is it possible to set the vernemq cluster up so that
published messages are not resend between all the nodes? This approach is
because I want to handle each messages on each of the nodes separately with
local subscriber on each node. Do you think its feasible?
Thank you.
On 5 November 2015 at 13:03, ioolkos<EMAIL_ADDRESS>wrote:

Closed #65 https://github.com/erlio/vernemq/issues/65.
—
Reply to this email directly or view it on GitHub
https://github.com/erlio/vernemq/issues/65#event-455637573.

Forgive me if I misunderstand. VerneMQ does not send a published message to all nodes, only to nodes where it finds out a subscriber lives. So you don't seem to want that?!
Can you give me the point I'm missing here? ;)

My environment looks like this: vernemq cluster on 3 nodes with load
balancer, which load balnaces incoming mqtt connections in round robin
schedule to the nodes. I would like to achieve handling mqtt message on
each of the nodes only once (on one of the nodes), thus I have a python
script handling the messages, subscribed to the particular node's IP. BUT
when I send mqtt message to LB, then it forwards it to one of the node, but
even though every python script is listening on it's own IP address of that
node, every node (and every python script) will receive that message - and
I want to be processed by only one node.
Maybe I am misunderstanding the whole vernemq cluster concept. I also
apologize if the question is out of the box. But thank you for your time!!!
:)
On 18 November 2015 at 17:15, ioolkos<EMAIL_ADDRESS>wrote:

Forgive me if I misunderstand. VerneMQ does not send a published message
to all nodes, only to nodes where it finds out a subscriber lives. So you
don't seem to want that?!
Can you give me the point I'm missing here? ;)
—
Reply to this email directly or view it on GitHub
https://github.com/erlio/vernemq/issues/65#issuecomment-157764421.

Hey @ioolkos, I am just wondering whether you got my point, or if am I missing something. Thanks!

@slavekdittrich apologies, Slavek, this slipped my attention!
I don't really understand the problem description though. Can you possibly re-phrase?
(where are the python scripts running? in what way are you seeing "multiple handling" of messages?)

I have 3 nodes running VerneMQ, IP addresses are <IP_ADDRESS>-203. In front of this cluster I have LB, which LB incoming MQTT connections to one of the nodes. LB from outside has <IP_ADDRESS> IP address. Thus I can have multiple nodes while preserving availability. On each node there is Python script, subscribed to local VerneMQ instance, i.e. subscribed to <IP_ADDRESS> on NODE1. So if I send MQTT message to LB, it will move it to one of the nodes, where I want the message to be handled by the subscribed Python agent. BUT somehow, the message is handled by every agent on every node.
NOW I UNDERSTAND. That's because every agent is subscribed to the same topic. Sorry about that.
Do you think there is a way how to handle the message only on one of the nodes?

Oh, I see what you want. You basically want subscriber balancing on a single topic, instead of fanout.
You can only do this by having the same clientID configured to use multiple sessions and then set the queue_delivery_mode to balance.
To balance different subscribers for the same topic, you'd probably have to write a plugin atm.

May I know where can I find the queue_delivery_mode parameter?
On 4 December 2015 at 15:15, ioolkos<EMAIL_ADDRESS>wrote:

Oh, I see what you want. You basically want subscriber balancing on a
single topic, instead of fanout.
You can only do this by having the same clientID configured to use
multiple sessions and then set the queue_delivery_mode to balance.
To balance different subscribers for the same topic, you'd probably
have to write a plugin atm.
—
Reply to this email directly or view it on GitHub
https://github.com/erlio/vernemq/issues/65#issuecomment-161977789.

You can add the following lines to vernemq.conf
allow_multiple_sessions=on
queue_deliver_mode=balance
(@dergraf any comments?)

Hm, I have to correct myself, currently the balancing of a queue is per node, so this is not automatically a cluster wide topic balancing.
So we might be out of luck here for your current use case.

Alright, thus I will need to find some other solutions. Anyways, thank you
for your time and for your help.
On 4 December 2015 at 19:13, ioolkos<EMAIL_ADDRESS>wrote:

Hm, I have to correct myself, currently the balancing of a queue is per
node, so this is not automatically a cluster wide topic balancing.
So we might be out of luck here for your current use case.
—
Reply to this email directly or view it on GitHub
https://github.com/erlio/vernemq/issues/65#issuecomment-162038633.

Let me thank you for your effort. And again, my apologies for the delay in answering.
BTW, I'm not sure any MQTT broker can do what you need out of the box.
Maybe you'll find away to split your traffic with an appropriate topic tree. Or with 3 single nodes instead of a cluster.


Revise interactive activities

We could have partner activities so that one partner tries Version A and another tries Version B.  We could also provide printed handouts with specific questions for the interaction components.

One good idea would be to partner advanced and beginner participants.  We will not know how to identify them though if we keep the pre-workshop survey anonymous.

Should we close this issue?

We can probably close it.  @csmagnano do you agree that our current version of the workshop addresses this?


crash with Fluidlogged API v2.2.7 when loading ingame

Describe the bug
A clear and concise description of what the bug is.
crash with Fluidlogged API v2.2.7 when loading ingame
Reproducibility
Please try to reproduce the issue with as few other mods as possible. Then check one of the following checkboxes according to your results. To check a checkbox, replace the space between the square brackets with an x (like this [x]) or create the issue and check the checkbox by clicking on it.

[ ] I reproduced this issue with as few other mods as possible installed.
[ ] I am unable to reproduce this issue consistently.

To Reproduce
Steps to reproduce the behavior:

Go to 'have Fluidlogged API v2.2.7 and load up the game and it will crash '

Expected behavior
A clear and concise description of what you expected to happen.
crash with Fluidlogged API v2.2.7 when loading ingame
Screenshots or/and videos
https://github.com/Red-Studio-Ragnarok/Alfheim/assets/87606666/9dfd5013-21a1-4778-8008-c7523276405a
Logs or/and crash reports
latest.log
Versions

Specification:
OS: [Windows 11]
CPU: [Ryzen 5 5500u]
GPU: [vega 7]
RAM Allocated: [4gb]

Duplicate of #4


Sitrep?

Hello,
What is the current status of this project, are we still waiting for:
https://github.com/intercept/intercept/issues/110 as mentioned in https://github.com/intercept/intercept/issues/168?
cheers
Lonja

re waiting for https://github.com/intercept/intercept/issues/110, wouldnt it be easier to build the objects in python  to build the higher level constructs?

Sure, but that is quite a lot of work to do and I honestly don't have the time and muse to start with it. I hoped I could use the classes from the helper library and only extend them here and there. Feel free to build something and pr it, even if it's just a tiny bit ;)

I think that this belongs more to the #1 topic and it's all more complicated than just using one PYTHON path variable. See #1 for my response.

Does not belong on issue tracker, please join our Slack if you want to discuss that.
To be clear, discussions about open issues or pull requests are fine, overall design discussions, asking for status on X does not belong on the issue tracker.

apologies, also not sure if it is just me but i cant connect to the slack given in the intercept/intercept readme (http://slackin-intercept.idi-systems.com/).

technician was notified.

I don't want to spam the issue tracker but you already have an account on that slack - I can see your username there is Tirpitz (but I guess that won't help you getting in).
Anyway, try recovering your password maybe. @Tirpitz93


fix mongodb write_block

core.write_block was passing the block already serialized to to the backend query. The problem is that mongodb uses a different serialization format.
With this change core passes a block instance to the backend query and the query serializes it as needed.

Current coverage is 96.64% (diff: 100%)

Merging #979 into master will increase coverage by 0.47%

@@             master       #979   diff @@
==========================================
  Files            35         35
  Lines          1827       2088   +261
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           1757       2018   +261
  Misses           70         70
  Partials          0          0

Powered by Codecov. Last update 7e33f2b...71bb633


[DataTatablePagination] Customizable info text

I noticed that text info settings are 'locked' to a certain format as in:
{showing_text} xx-xx {from_text} xxx ${data_text}
Considering not all language are formatted the same way and some design may required more customized text that may require some of the value omitted, for example: [itemsPerPageInput] from 40 datas.. It may be more flexible to give, for example, an infoText prop which expects a string or a callback like below so user can customize their texts as their wish.
<v-data-table-pagination
    :info-text="(currentPage, itemsPerPage, totalItems) => { return "whatever string here"; }"
/>

Also, ability to show or hide the info text or any particular "content" of the pagination would be greatly appreciated! Sometimes, we don't need those info text, or ability to change itemsPerPage after all.
// package.json

"@gits-id/ui": "^0.10.12",

Thanks for the feedback. Maybe we will add slots for custom text. PR is welcome.

Done in<EMAIL_ADDRESS>Checkout example here: https://gits-ui.web.app/?path=/story/components-datatablepagination--meta-slot


Update api_key_id definition

API Key ID was defined as "everything after the middle dot in the API key" but an API Key ID is everything before the middle dot in the API key. ex SG.xxxxxxxxxxxxxxxx. Feel free to create a better dummy API Key ID.

Description of the change:
Reason for the change:
Link to original source:

Closes #

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

Hello @emilyruppe,Thanks again for the PR! We want to show our appreciation by sending                                              you some swag. Could you please fill out                                              this form so we can send it to you? Thanks!                                             Team SendGrid DX


Update openstack module in salt-cloud

Update to add project name into list_nodes_full.
Add list_projects, get_compute_limits

Committed: 970b7a8d641388fc78850425f9da6bd8ff586f66

In the case of list_nodes_full, a project argument is added into the "kwargs" is better because if that is applied several provider files are not needed.
So, I'm going to check it out to able.


Help with config

So i just converted my binds over from kwm, and i'm getting 'Expected token of type 'Token_Command' after symbols!'. Not sure why.
Here's my khdrc. Any help appreciated.
https://gist.github.com/anonymous/5723e328967c91f3b2e93374c5223c56

I don't think , and . are valid anymore. You need to specify these using the keycode.
See #1 for how to figure out the keycode you need.

thanks!


Bug in : display_remaining_budget() takes 2 positional arguments but 3 were given

ERROR:root:display_remaining_budget() takes 2 positional arguments but 3 were given
Traceback (most recent call last):
File "/workspaces/DollarBot/code/add.py", line 135, in post_amount_input
helper.display_remaining_budget(message, bot, selected_category)
TypeError: display_remaining_budget() takes 2 positional arguments but 3 were given

this issue appeared before, but I still got the error report

Has this issue been solved?

Has this issue been solved?

Yes! I refactor that function, and now everything looks fine.


Missing delete method

The DB class still misses a delete method to completely remove named objects like maps from the store.
You can find comments:
//TODO consistency lock
//TODO rename nemed object
//TODO delete named object
//TOOD metrics logger

From those the delete method is actually quite important if you use a store with dynamic named objects and want to reclaim all resources no longer needed.
There has been no activity for 2 years on this project. @jankotek is there any plan to continue work on mapdb in the near future?

I'm not sure about the near future, but the blog entry made me hopeful: https://mapdb.org/blog/mapdb4-announcement/


feat: index account/storage history

ref: https://github.com/paradigmxyz/reth/issues/815

Codecov Report

Merging #978 (c1931ba) into main (c7289bd) will increase coverage by 0.46%.
The diff coverage is 97.81%.

@@            Coverage Diff             @@
##             main     #978      +/-   ##
==========================================
+ Coverage   74.01%   74.47%   +0.46%
==========================================
  Files         294      297       +3
  Lines       32564    33293     +729
==========================================
+ Hits        24102    24796     +694
- Misses       8462     8497      +35

Flag
Coverage Δ

unit-tests
74.47% <97.81%> (+0.46%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

crates/stages/src/test_utils/test_db.rs
66.94% <ø> (ø)

crates/storage/db/src/tables/mod.rs
0.00% <ø> (ø)

crates/storage/db/src/tables/models/mod.rs
85.71% <ø> (ø)

crates/storage/provider/src/db_provider/storage.rs
17.79% <0.00%> (-0.31%)
:arrow_down:

crates/stages/src/db.rs
88.59% <89.65%> (+0.25%)
:arrow_up:

crates/stages/src/stages/index_account_history.rs
98.42% <98.42%> (ø)

crates/stages/src/stages/index_storage_history.rs
98.55% <98.55%> (ø)

crates/storage/db/src/implementation/mdbx/mod.rs
98.04% <100.00%> (+0.06%)
:arrow_up:

crates/storage/db/src/tables/models/sharded_key.rs
100.00% <100.00%> (ø)

...torage/db/src/tables/models/storage_sharded_key.rs
100.00% <100.00%> (ø)

... and 4 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

I added an additional change to indices and set the last shard to be (Address, u64::MAX) it is a small change but would allow us faster fetching of shard that contains our transition id.
Just using seek_exact would fetch us the TransactionList that we need while previously we would need to use cursor prev to get to latest shard and check if it contains our transition list.


Automated cherry pick of #2487: Fix test-upgrade-antrea.sh script so it can be used in

Cherry pick of #2487 on release-1.1.
#2487: Fix test-upgrade-antrea.sh script so it can be used in
For details on the cherry pick process, see the cherry pick requests page.

Codecov Report

Merging #2510 (b5d3079) into release-1.1 (dafc994) will decrease coverage by 0.05%.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           release-1.1    #2510      +/-   ##
===============================================
- Coverage        62.01%   61.95%   -0.06%
===============================================
  Files              278      278
  Lines            21161    21161
===============================================
- Hits             13122    13111      -11
- Misses            6682     6690       +8
- Partials          1357     1360       +3

Flag
Coverage Δ

kind-e2e-tests
53.12% <ø> (-0.08%)
:arrow_down:

unit-tests
41.35% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/apiserver/certificate/cacert_controller.go
58.27% <0.00%> (-7.95%)
:arrow_down:

pkg/apiserver/apiserver.go
89.51% <0.00%> (-1.62%)
:arrow_down:

pkg/agent/agent.go
50.34% <0.00%> (-1.38%)
:arrow_down:

...agent/controller/traceflow/traceflow_controller.go
72.08% <0.00%> (-1.07%)
:arrow_down:

pkg/controller/traceflow/controller.go
71.68% <0.00%> (ø)

pkg/controller/networkpolicy/status_controller.go
87.09% <0.00%> (+0.64%)
:arrow_up:

pkg/agent/flowexporter/exporter/exporter.go
80.04% <0.00%> (+1.37%)
:arrow_up:

pkg/agent/flowexporter/connections/connections.go
87.80% <0.00%> (+7.31%)
:arrow_up:

pkg/agent/flowexporter/exporter/certificate.go
66.66% <0.00%> (+16.66%)
:arrow_up:


[$500] iOS - Notificiation - New messages are not shown until user is online after selecting notification

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.2-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:

Login in primary and secondary device as User A and User B respectively.
Close app on primary device and send message to User A using the secondary device
After User A receives notification, disconnect device from internet
Wait 10 seconds and double tap on notification received on primary device

Expected Result:
App opens to chat and new message is seen
Actual Result:
App opens to chat and new message is not displayed until user reconnects to internet
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[x] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/34783dbc-896a-48d3-8424-b954324d5859
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01241a0e0884e93cf1
Upwork Job ID:<PHONE_NUMBER>284608000
Last Price Increase: 2023-12-06

I could not recreate the issue using new expensify app in the app store nor in an ios simulator. can you provide more details

Proposal for Issue #31765: iOS - Notification - New Messages Not Displayed Until Online After Selecting Notification
Please re-state the problem that we are trying to solve in this issue.
In the iOS version of the app, when a user receives a push notification for a new message, selecting the notification does not display the new message until the user reconnects to the internet. This happens when the app was previously closed and the device is offline at the time of selecting the notification.
What is the root cause of that problem?
The issue likely stems from the app's handling of push notifications and local data synchronization when offline. The push notification handler (index.native.js) might not be updating the relevant Onyx keys (like ONYXKEYS.NETWORK) to reflect the arrival of new messages when offline. Additionally, there might be gaps in how the app manages AppState transitions and utilizes cached data in Expensify.js.
What changes do you think we should make in order to solve the problem?
To address this issue, several modifications are proposed:
Update Push Notification Logic: Enhance the push notification handling in index.native.js to ensure that relevant Onyx keys are updated properly when a notification is received, regardless of the online/offline status.
Optimize Onyx Local Storage Usage: Revise local storage handling to ensure that new messages are cached and retrieved effectively when the app is launched from a notification while offline.
Improve AppState Transition Management: In Expensify.js, refine the management of AppState transitions to check and update the UI with new messages when the app resumes from a notification.
Synchronize Messages with Session Data: Guarantee that session data (ONYXKEYS.SESSION) is correctly maintained or restored, especially for syncing messages related to the session.
Implement Offline Feedback: Utilize OfflineIndicator.js and OfflineWithFeedback.js to provide immediate feedback on the message's offline status and display messages correctly in offline mode.
What alternative solutions did you explore? (Optional)
N/A
By implementing these changes, we can ensure that the app correctly displays new messages when opened from a notification, even in offline scenarios. This approach aims to enhance the user experience by addressing the core issues related to push notification handling and data synchronization in offline mode.

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~01169c49d59fd10b60

I think we're still waiting for more proposals here!

I don't think we should increase the price on this one as it's a bit of an edge case issue (offline > online with slight delay)

will give this one a but more time for proposals

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~017ca78778741aa14c
To address this issue, I propose the following steps:  Offline Data Handling: Enhance the app's ability to cache data, ensuring that recent messages are stored locally. This will allow the app to display new messages even when offline. Notification Interaction: Modify the notification interaction so that tapping on a notification triggers the app to fetch and display the relevant message from local storage if an internet connection is unavailable. Data Sync: Implement a background sync mechanism to update the local cache when the app regains an internet connection, ensuring data consistency. Testing: Rigorous testing on all supported platforms (Android/iOS native and mWeb, MacOS Chrome/Safari, MacOS Desktop) to ensure the solution works seamlessly across all platforms. Implementation Plan:  Analysis & Design: Detailed analysis of the current React Native codebase to identify optimal points for integration of offline data handling and notification interaction enhancements. Development: Incremental development of the proposed solution, ensuring that each step is thoroughly tested. Collaboration: Regular communication with the Expensify team via GitHub and Slack to ensure alignment with project goals and coding standards. Testing & Documentation: Comprehensive testing across all platforms, along with clear documentation of changes made. Pull Request: Submission of a pull request with detailed descriptions, screenshots, and test results for review by Expensify engineers.

@arhyp
Welcome to Expensify! Please ensure to read the contributing guidelines and check out a few other issues with other contributors' proposals to get a feeling of how the Expensify process works.

@cubuspl42 any feedback on the two proposals above?

Neither of the proposal properly sticks to the template, which is just a tip of the iceberg. This is not the kind of the issue which I expect to be solved be newcomers, if it can be solved externally at all.

Messages got into spam, sorry.
Yes, will check and reapply
Thanks

On Dec 8, 2023, at 1:20 AM, Jakub Trzebiatowski @.***> wrote:
Neither of the proposal properly sticks to the template, which is just a tip of the iceberg. This is not the kind of the issue which I expect to be solved be newcomers, if it can be solved externally at all.

I guess that while the expected behavior is reasonable, any solution achieving it would be considered too complex to implement. Let's just ask for an internal engineer's opinion.
🎀 👀 🎀

@bondydaa Do you think that it's likely that we could implement a feature like this...

The user receives a notification about a new message
The user loses access to the Internet (or manually disables it)
The user enters the previously received notification and opens the app, seeing it up-to-date with the messages they received the notifications about

...either....

externally, having in mind the complexity
internally, having in mind the current priorities

I think we should close this one - it seems complex and related to a larger question about offline mode and updates. I think we'll just have this sitting here for a while without getting traction

Hmm yeah I'm not too up to date with our current plan for pushing all data out to user but I believe this is part of the Reliable Updates stuff that Ioni is working on is all about.
I think we close this out for now in favor of waiting until that project is done... I agree that if you were able to get a notification that then we'd expect also that the data has been pushed to your device so it's strange but also a known problem we're working on fixing.
I think in a scenario where this would actually happen to a user who is on a spotty connection the message would show up quick enough or they probably wouldn't receive the notification at first anyways so I think this is pretty minor.


[Spdy] Spdy component

We could implement the spdy protocol, possibly by porting the igrigorik/spdy ruby gem. This would be a "Spdy" component that integrates with the Http one.

Moved to https://github.com/reactphp/http/issues/99


chore(use-case): refresh tests for latest cdk and constructs

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 19d99ff40396410e535fe2e2e3c4868952236be2
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 99fb74518193bd0ff70f98af0c4724a8da2c3d0d
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository